727 karma · joined February 18, 2011
en@ig.ma
https://github.com/nigma/
First of all the project is based on llama.cpp[1], which does the heavy work of loading and running multi-GB model files on GPU/CPU and the inference speed is not limited by the wrapper choice (there are other wrappers in Go, Python, Node, Rust, etc. or one can use llama.cpp directly). The size of the binary is also not that important when common quantized model files are often in the range of 5GB-40GB and require a beefy GPU or a MB with 16-64GB of RAM.
The best part about C64 was it immediately booted into a Basic prompt that invited you to experiment with the hardware, like typing these magic POKE commands to set screen and text colors.
I'm not actively involved in the package development anymore but it is still maintained [3] and there is a great chance that you have it already in your Python environment as a dependency of scikit-image/scikit-learn. Just give it a try, it's very simple:
>>> import pywt
>>> cA, cD = pywt.dwt([1, 2, 3, 4], 'db1')
SQLite is primarily embedded/local database and cannot be easily separated and shared over network [1] between multiple disposable backend/worker instances.
Also many ad-blockers that could filter app traffic were nuked from the App Store. I wish there was a way to firewall network traffic in the same way it is possible on other systems.
In other words if I buy a phone with 2y warranty (a standard duration in many European countries) it would be reasonable to expect that any security updates (device fixes) will be provided in a reasonable time within that period starting from the purchase date.
AWS product basically consists of open remote sensing datasets uploaded to S3. This is convenient if you deploy on AWS (transfer costs) but still have to develop all the data processing.
There are some sites that require JS to render, but the great thing is that majority of pages I visit work just fine as plain html/css. In general I feel less distraction from popups, overlays, ads, etc.
If you happen to be running this device you may want to apply precautionary measures.
But to be fair one should point out that Apple is also collecting telemetry data (search system logs for com.apple.telemetry) without any toggles in the system preferences.
Search results don't bring much info on what is collected and how it is being used. Does anyone here have insight into Apple telemetry granularity?
The link leads to a staging version of the store.docker.com site that is indexed in google.
import base64
base64.urlsafe_b64decode(s)Backend and frontend development, mobile APIs, devops.
I usually do Python, Django, mobile backends, PostgreSQL/*DB, JS, Angular, Scala, Go, system architecture, database design, automation, devops (Ansible, Salt) and whatever it takes to get the job done.
I'm capable of executing all stages of projects, starting from a customer idea and ending with a ready, deployed product. I have a broad technical and domain-specific knowledge (medical, financial, automotive, location-based services, machine-learning, analytics, wavelets) and several years of experience working for startups, business customers and open-source.
I deliver several projects a year. Here's some of my work:
Drop me an email at en@ig.ma
PS. I'm open to cooperation with other freelancers (design, mobile, web, etc.).
Open/LibreOffice with Python bridge is quite handy in converting documents to PDF format and can be run in headless mode (using virtual frame buffer like xvfb) on a server.
The whole design of DRF makes a lot more sense for my use cases.
TastyPie provides you with Resources that do everything from accepting and dispatching methods, querying db, authentication and authorization to parsing an serializing data. If you want to modify one puzzle you have to redefine the resource.
In DRF the separation between request processing, data serialization/deserialization, rendering and other elements is more clear.
API endpoints are just views that are based on Django class-based views so you should already know how to customize them, do queries and use mixins. Serializers perform data validation (similar to forms, but can handle collections and relations) and conversion between objects and native Python datatypes. They can also be reused in multiple views or for nested relations. Other components are pluggable so you can specify parsers, renderers and auth backends for the whole API or for just a particular view.
The Rest Framework just feels right and works well when you need to do any sort of customization. On top of that you get a very detailed documentation and a browsable API.
TastyPie served me well for a long time and I'm very thankful to the developers, but I find DRF to better suit my needs.
Thank you for contacting us. We have no evidence at this time that any payment information was compromised.I really hope that hardware makers will finally realize that the primary reason for buying a notebook is not for watching movies on a 15" screen.
It would be great to know more about your new setup, i.e. do you use streaming replication and some resource manager like Pacemaker?
Regarding the quality of reusable apps, well, it's like with all other software libraries out there. Some of the apps are really invaluable (mostly the utility ones addressing things like API creation, database extensions, forms or debugging), some of them address very specific problems and some of them should't ever see the daylight. Nothing new.
The thing is that the TODO application is way too simple and does not require solving any meaningful problems. A much better and more realistic sample app would include at least handling basic relations between objects like users commenting under articles or voting on submissions. Say simple HN in JS MV* implementation would be a lot better resource.