thanks for reply, good instrument!
but a step back: what is a proper way to put blob into sql? For example, if to
try to put zip-compressed text data it falls with DbError:
import db_sqlite
import zip/zlib
let db = open("mytest.db", "", "", "")
let str =
"Asamplel
They are the same thing, we just came up with a better name and wanted to
rename flippy, but also totally change the API. Pixie is just flippy 2.0 kind
of with way more functionality. It started as flippy 2.0 but it ended as flippy
20.0 :)
Don't use flippy, use pixie instead.
Whats the difference between Flippy and Pixie ?, why they are not the same
thing.
For reading a BLOB column, I recently wrote a helper function like below - note
that it will only work with `instantRows`:
import std / [db_sqlite, sqlite3]
proc blobColumnAt*(row: InstantRow, index: int32): string =
## Retrieve the value at index column as BLOB.
I'm curious to know the rates from you guys here for hiring Nim developers full
time.
I've built software on my own with Nim, one netting me a little over $10k since
December. What was originally a venture to build my own tools to help with my
consulting work turned into something I hadn't real
I apologize. I thought I had tested all of the examples. I am not sure why it
doesn't work. There doesn't seem to be any refs that are GC'ed which would be
the issue, so not sure why it would be an issue.
Many, many thanks for this in in-detail explanation. Please add (something
like) this to the documentation of the **parallel** clause. I myself have to
digest the **FlowVar** construct first.
Is there a typo in your third version? It doesn't compile here (development
Nim) The line in error is f
I would start with a custom Table and seq and string implementation (DiscTable,
DiscSeq, DiscString) and then see how the programs really work out. Usually
code out there assumes that state changes are not persistent -- the data is
gone after the process died. This assumption doesn't hold for yo
I think the best you can do right now is map your memory in a known address
(this is nearly impossible in 32-bits, but address space in 64-bit is vast
enough to declare something "yours"). There might be collisions if someone else
wants to do the same, of course
Using stdlib data structure
Though `sameFile` seems the answer for @RainbowAsteroids, since someone might
search the forum and wind up here and since my dups example has way more going
on than necessary for just this and is not standalone, here is how one might do
a "print sets of referrers" style query:
imp
Why is it important: technology already and some years ago provides the
non-volatile RAM, which saves its state after the full power down (Intel
Optane, HPE NMDIMM's). What is much more important that modern OSes a long time
ago provide the ability to extend any program address space via `mmap`
I see. Hm that complicates things. Idk how practical that would be, but how
about something like this:
type
PMemPtr[T] = distinct int
var pmemHeapStart: ByteAddress
proc `[]`[T](pmemPtr: PMemPtr[T]) =
cast[ptr T](cast[ByteAddress](pmemPtr) + pmemHeapSt
I don't want to access it -- I want to use Nim as a persistence-enabled
language, with all its power of dynamic structures (mapped to SSD or NVDIMM).
But I don't think it is possible -- I must implement not only custom GC but
integrate these "offset/based pointers" into the Nim core or at least
Maybe I should especially note: the PMEM base address moves randomly across the
address space between every program run. That's why generic pointers not
acceptable -- they use the absolute address, but I must address relatively to
the BASE randomly moving in memory.
14 matches
Mail list logo
