***pc is now known as Guest34119
<redkahuna>Hey all,Is there in guile something like import pdb; pdb.set_trace(); of python ? <amz3>redkahuna: no, I use (pk 'foo 'bar 'baz) that prints all arguments and return the last argument. <amz3>I considering the use of a sortable unique identifier (something that is easy to sort) for a database system. I already tried purely random bytes, it cause lot of fragmentation. So, I read about ULID (https://github.com/ulid/spec#specification) <amz3>what I am wondering is about the timestamp in millisecond. As far as I know, guile provides on microseconds precision with gettimeofday. <amz3>I want to optimize the thing, to avoid any transaction restart because commit-rollback-commit takes time. one reason for a transaction restart might a write-write conflict over the same uid hence the idea of random bytes. <amz3>otherwise said, a given write transaction should spend less than 500ms and it should not restart because of write-write conflict. <amz3>there is tradeoff between timestamp precision and the number of random bytes, but I don't know how to make a wise choice. <amz3>nevermind, I will benchmark it later with the whole program. It will be easy to change. <amz3>Still it is strange that they choosed milliseconds in ulid, instead of nanoseconds like gettimeofday provides. Also it would be better to put after the timestamp, 16 bits identifiying the processor to reduce fragmentation even more. <amz3>(write-write conflict can happen because the nstore and full-text search will only store those idenfiers, and a mapping between the identifiers and the actual value will be provided in another subspace of the okvs) <amz3>(there will be a race at index time, especially at cold start, to acquire identifiers for every words that appear in natural language) <jcowan>amz3: What do you mean by "fragmentation"? <RhodiumToad>most likely the well-known problem with, e.g., btree indexes on a database - inserting values in random order gives you an index that doesn't perform as well as one inserted sequentially <amz3>also random bytes will not trigger prefix compression algorithm. <amz3>one rebalance the tree, but it takes time. <amz3>one *can* rebalance the tree, but it takes time. <amz3>I am not sure "rebalancing the on-disk representation" is a thing in any okvs. It would be too much costly. <jcowan>I'm currently using UUIDs (both random and in some cases DNS-based) because I have to guarantee that a row can be copied across multiple databases with different data owners without a collision <jcowan>Yes, I see why in OKVSes it's a problem <amz3>jcowan: what kind of OLTP like pgsql or sql server or oracle? <jcowan>Online transaction processing in general, which nowadays is non-stop and 24/7/365. <wingo>faithfully modelling the weird semantics of with-throw-handler is tricky :) <ArneBab>wingo: did you see my note about (graphing)? <wingo>ArneBab: i think i missed it; link? <ArneBab>wingo: I tried charting, but the example throws an error: ERROR: In procedure cairo-image-surface-create: Wrong type (expecting exact integer): 305.0 <ArneBab>wanted to try it, because I wanted to get rid of having to switch to gnuplot to do quick charts <ArneBab>plus it looks pretty solid — the kind of visualizations I’d like to give quickly <wingo>humm, where did you check it out from <wingo>should make another release i gues <wingo>gitlab.com/wingo/guile-charting *wingo down to 4 test failures for rewrite of throw/catch on top of with-exception-handler/raise <ArneBab>wingo: this one works, yes. I new release would be great! <wingo>on my list, plz poke if no release in a week. not tonight tho :)