IRC channel logs


back to list of logs

<marmulak>the only way I could figure out how to solve this in haskell was to read in all the data, split it where there is a comma, and then split the results again on space and then return the last element <email> skipping < or >
<marmulak>so the data gets copied multiple times
<marmulak>it's probably the solution that uses the most memory
<Aurora_iz_kosmos>Hm. You could generate a datastructure with separators & offsets in one pass then use those offsets for either generating an intermediate list or directly operating on the elements.
<marmulak>what I wrote today in scheme (that I suck at) is that it does a loop where it reads in a string delimited by whitespace, then tests it so that it contains @ and no quotation mark, then outputs the result with "<>," deleted
<Aurora_iz_kosmos>I see.
<marmulak>it might actually be the better way but it runs slower than haskell or C ;)
<marmulak>although on most of the tests I ran it was not far behind
<Aurora_iz_kosmos>It's interesting that you're more familiar with Haskell than Scheme.
<Aurora_iz_kosmos>The latter is generally seen as more newbie-friendly.
<marmulak>not anymore XD
<marmulak>I tried to study Haskell for a week or two last year and probably forgot most of it by now. The learning curve was steep, Scheme does feel easy by comparison
<marmulak>this program I write is just a proof of concept because I wrote it years ago in C++ but shouldn't have, only because C++ was the only language I knew
<marmulak>so I like to do this "hey look this program I wrote in 50 lines is only 5 lines in scheme)
<Aurora_iz_kosmos>For industry-related reasons, you should probably get some minimal proficiency in Python
<marmulak>sorry, that parenthetical mark was reflex
<Aurora_iz_kosmos>If you don't have it by now, that is.
<marmulak>yeah I know python is so big
<marmulak>I just really wanted to learn functional programming
<Aurora_iz_kosmos>That's fair and relatable.
<marmulak>the thought of learning python makes me feel like I'm going back to QBASIC again
<marmulak>QBASIC for Linux
<Aurora_iz_kosmos>It's not that bad. Think of it as pseudocode you can actually run.
<dsmith-work>There are worse things than Python
<dsmith-work>Not my favorite though
<marmulak>I'm proud though, today I wrote a program that does something in a lisp-like language, as opposed to evaluating (+ 1 1) in emacs and then going "ok"
<marmulak>it's more than a calculator now!
<Aurora_iz_kosmos>I find Python's one of the least annoying major scripting languages with a decent library ecosystem.
<marmulak>oh yeah it's very strongly supported
<marmulak>btw about scripting with guile, for invoking shell commands I am going to use the (system) function every time, right?
<dsmith-work>Looks at (system*) too and pipes
<marmulak>as for your suggestion of using a datastructure with offsets, I am not sure I would know how to do that
<marmulak>dsmith-work: thanks
<jcowan>Python is excellent for whiteboard interviews for the reason Aurora_iz_kosmos gives
<dsmith-work>system* doesn't use the shell
<marmulak>does (while) have a negative counterpart like (unless) is to (if)? I thought it should have existed by my program instead uses (while (not))
<Aurora_iz_kosmos>Hm. Can't remember syntax macro atm, something like (defmacro until (condition body) (not ~condition) ~@body)
<mwette>(define-syntax-rule (while-not cond body ...) (while (not cond) body ...))
<mwette>unless is taken already
<Aurora_iz_kosmos>Ah my bad.
<Aurora_iz_kosmos>Hm, it's not in my 2.0 manual, what does it do?
<mwette>(unless cond body ...) == (if cond (begin body ...))
<mwette>oops -- (if (not cond) (begin body ...))
<mwette>(when cond body ...) == (if cond (begin body ...))
<dsmith-work>(define-syntax-rule (until cond body ...) (while (not cond) body ...))
<dsmith-work>sneek: Later tell wingo, I
<dsmith-work>sneek: later tell wingo I'm also getting Illegal instruction on a fresh rpi3 Buster install. Guile built from source, default config.
<sneek>Got it.
<lampilelo>you get illegal instructions? from the mob?
***karlosz_ is now known as karlosz
***cantstanya is now known as Oxford
***Oxford is now known as frank
***frank is now known as cartwright
***cartwright is now known as cantstanya
<daviid>spk121: did you manually wrap every single tree/store set value function? in guile-gi i mean ..
<spk121>daviid: not exactly sure what you mean, but, probably not. We only manually wrapped very few functions, so if they weren't in the .gir / .typelib they only got special treatment if they were types that appeared in .gir, like GHashTable and such
<spk121>oops, that sentence made no sense.. what I mean is that we only wrapped some pretty fundamental types so we could most of a .typelib
<daviid>ok, then this (gtk-list-store-set-value store iter column value) won't work in guile-gi (as it won't work in any binding), not any function th expect a pointer to a GValue ...
<daviid>unless we wrap thse manually (which is what guile-gnome and pygobject does ...)
<daviid>i was hoping 'modern' GI provided a way to overcome this (terrible) limitation, but it seems somehow imposible, hence the necessity for manual wrap of those
<daviid>I am thinking of a way to over come this automatically, and I can only think of tracking those at import time, then force an additional arg on users, whch is not 'beautiful', but efficient
<daviid>or otherwise, manually wrap 'à la guile-gnome'
<spk121>some of the gtk_list_store_insert_sorted seems to parse, but, that's it
<daviid>spk121: yes, i parse all of them, but they will fail at call time ...
<spk121>actually, we do end up parsing <GtkListStore> and the parent <GListStore>, so when both load up, the GListStore methods seem to cover the basic operations.
<daviid>spk121: but you require user to initalize GVlaue(s) themselves then
<daviid>this should fail in guile-gi: (gtk-list-store-set-value store iter 0 10) or (gtk-list-store-set-value store iter 1 "hello, world") - assuming store and iter are 'ok' of course, but that is working fine ... the problem is the value
<daviid>given store being (gtk-list-store-newv 2 '(int string)), and iter being (gtk-list-store-insert store 0)
<daviid>spk121: here is what needs to be done for these functions to work, the list-store set-vlue is just of them of course: - line 358 and below ...
<spk121>daviid: well to be honest there's nothing in the test suite that has tried to use <GtkListStore>. I'd have a look and see if the <GListStore> methods that to get autogenerated are sufficient to write something in scheme only, because we have been avoiding creating a hard dependency on Gtk in guile-gi
<spk121>in the C part of guile-gi, that is
<daviid>they can't be sufficient, by design, I was wondering if you did think about a mechanism (which will be either ugly or quite complex) that we could omehow share ...
<daviid>a mechanism other then manually wrap/override them I mean
<daviid>spk121: here is a example for you to 'trnslte' to guile-gi and play with ... - which fals on line 57 as 'expected', and will fal until I manually wrap gtk-list-store-set-value
<spk121>OK, cool. Lemme check it out
<daviid>wc! I'd be happy to read the guile-gi code for this example, just curious ...
<str1ngs>hello alextee[m], do you have an example of a GTK transfer annotation? I just want to return a pointer nothing? also is there any caveats with this that you know of?
<str1ngs>alextee[m]: nothing special*
<str1ngs>alextee[m]: sorry for the noise I found an example here.
***wleslie is now known as verte
***verte is now known as wleslie
<spk121>daviid: I think it would end up looking like this
<spk121>but I haven't implemented input arguments that are arrays of GType, and input arguments that are arrays of GValue
<daviid>ah ok will look asap tx - then you'll see what i'm talking about when you do .. :):)
***gal is now known as galex-713
***galex-713 is now known as gal
***gal is now known as galex-713
<wingo>civodul: hey i had a thought this morning
<sneek>wingo, you have 2 messages!
<sneek>wingo, dsmith-work says: I
<sneek>wingo, dsmith-work says: I'm also getting Illegal instruction on a fresh rpi3 Buster install. Guile built from source, default config.
<wingo>good morning btw :)
<wingo>to lower bootstrap time, and possibly as a reasonable solution for fast -O0, we can write a compiler from tree-il directly to bytecode
<wingo>just using stack techniques
<wingo>i think we might even be able to get reasonable debug info from it as well
<civodul>hello wingo!
<civodul>oh, wild :-)
<civodul>but yeah, why not!
<wleslie>I saw this word the other day and thought of you, andy:
<civodul>though i think we should also invest in profiling and getting a better understanding of what happens with intmaps and all
<wingo>civodul: do you know what fraction of guix pull time is expand vs what proportion is compile?
<civodul>not sure
<civodul>the "Computing Guix derivation" bits (~1mn on modern hardware) is purely evaluated and largely expand
<wingo>civodul: i also have a wip patch to reimplement intsets as trees of bitvectors. goal would be lower tracing load and make access cheaper
<wingo>but i don't have perf numbers yet
<civodul>for me simply gcprof compile-file of one of the relatively large files in Guix is a good benchmark
<wingo>i started with an inlined implementation of bitvectors (u32vector / u64vector) but i realized i should just make sure bitvectors compile well
<civodul>you mean bitvectors instead of bignums?
<wingo>intset doesn't use bignums
<wingo>intset uses a tree, where a tree node is a vector or a fixnum
<civodul>well the key can be a bignum i guess, but yes :-)
<wingo>but having a vector of fixnums is a bit silly, allocation-wise
<wingo>civodul: pretty sure we will never see a bignum as an intset key!
<civodul>ah oh, maybe i'm confused then
<wingo>the bignums you were seeing in the slot allocator were really bitfields
<wingo>i.e. a bitmask where each bit indicates whether the slot is occupied or not
<wingo>pretty sure set that are like "which variable is live here" are intsets there
<wingo>not bignums
<civodul>hmm my memory is fuzzy
<civodul>but we do use bignums pretty much for those bitmasks, no?
<civodul>like when we do (1 << label) or things like that?
<wingo>there are a few differnt kinds of bitmasks
<wingo>we don't do 1 << label as a bignum
<wingo>we use a bitmask for that
<wingo>sorry, intset
<wingo>we only do 1 << slot as a bignum
<civodul>ah that, yes
<wingo>thinking there would generally be fewer than 30 or 62 slots
<wingo>but apparently that's a terrible assumption :)
<civodul>heh :-)
<civodul>it means performance degrades significantly when you go beyond 60-something slots
<civodul>it makes it non-linera
<civodul>the other issue is memory consumption, it's really fishy
<wingo>probably should fix that, though it's tricky :)
<wingo>anyway for modules for which an optimized compile aren't important, we can sidestep the problem
<wingo>don't build CPS, don't run slot allocation, just make the bytecode mirror the stack discipline
<civodul>how much work does that represent?
<wingo>that was my question for you :)
<civodul>ah good, dunno :-)
<civodul>i'd have to look
<wingo>i.e. wondering how much of guix time was taken by expand vs compile
<wingo>ah, you mean to hack it up
<civodul>oh i was wondering about human work time
<wingo>i think i could make a compiler like that in 3-5 days
<wingo>but where to find those days is another question :)
<civodul>heh :-)
<wingo>wleslie: tx for the link, interesting!
<civodul>expand time is not significant when compiling gnu/services/mail.scm or something like that
<wingo>you are sure there?
<wingo>just checking
<wingo>i mean i know guix has lots of macrology
<civodul>right, i can try and get actual figures
<civodul>wingo: this should give a rough idea:
<wingo>hehe yeah
<civodul>that'd mean ~11% of the time is parsing + expansion
<wingo>so the most we could expect would be 10x speedup or so, not bad
<wingo>making a baseline compiler like that would lower memory usage as well
<civodul>i guess so
<wingo>which i guess has some good implications for the guix use case
<wingo>i think but i don't really know that load-time for guix modules would be largely unaffected
<wingo>the package modules i mean
<civodul>what do you mean?
<wingo>i guess you would compile the guix module tree using the optimizing compiler and gnu/ with baseline
<civodul>that would only affect compile time
<wingo>well, the compiled file size would be different
<wingo>and the result may allocate more, if some optimizations aren't applied
<wingo>and it will do more work at load-time i think
<civodul>ah yes, i see
<wingo>so (use-modules (gnu packages foo)) might take longer
<wingo>but i think not.
<wingo>we'll see i guess
<civodul>on a smaller file:
<civodul>8% here
<alextee[m]>str1ngs: sorry havent used these annotations before
<guix-vits>Hi Guile.
<guix-vits>Blackbeard: u're yet 'ok', or any better today?
<str1ngs>alextee[m]: no worries, I found what I needed
<janneke>hmm, i've got some code here that runs 5x faster when wrapped it `statprof' (guile-2.2.6)
<wingo>wtf :)
<janneke>yeah! trying to look into it; it's a nontrivial amount of code and data
<janneke>what i seem to notice just now, is that in `top' the non-statprof version jumps CPUs all the time
<dsmith-work>Happy Friday, Guilers!!
<janneke>hello dsmith-work!!
<civodul>hey, happy Friday!
<stis>yeah, got a new version of my python clone out
<mwette>Hi all.
<mwette>Maybe I should add a COBOL->TBD translator to nyacc.
<jcowan>Or better yet a Cobol language feature for Guile
<jcowan>Cobol control flow is complex, and targeting a properly tail recursive language has real advantages
<brendyyn>stis: thats amazing :)
<RhodiumToad>cobol probably comes nearer than any other real-world language to having an actual COME FROM
<RhodiumToad>in that you can PERFORM a range of paragraphs, and there's no indication within that range that control might drop back to some caller
<wingo>janneke: the difference with statprof is that periodically you get a SIGPROF call, which will wake up some things
<wingo>either it's a bug in guile that it's waiting when it shouldn't, or it's a bug in the kernel that it's waiting where it shouldn't
<wingo>strace while doign statprof might give you the answer, to see what syscall was current when the SIGPROF arrived
<janneke>wingo: that's smart; i'll have a look at that
<jcowan>RhodiumToad: Right, so compiling each paragraph into a separate procedure means that GO TO compiles into a tail call and PERFORM into a call to a metaprocedure that invokes procedures in their lexical order. The mainline execution, then, is just PERFORM <first> THRU <last>.
<RhodiumToad>makes sense
*RhodiumToad hasn't had cause to touch cobol in many years, fortunately
*jcowan either
<jcowan>there is more talk on #cobol right now than there has been in a month of Sundays.
<RhodiumToad>I'd be surprised if there weren't people running production cobol programs today that are older than I am
<RhodiumToad>(and I'll be 52 in a month)
<jcowan>I'm 61 and I've only ever written one program in Cobol. I volunteered to write it as an extension of working as a consultant, but the manager who wanted it said it had to be in a language he could easily maintain. Cobol it was.
<jcowan>I admit to taking advantage of Cobol's full abbreviative capabilities
<mwette>in response to ,locals I get: $16 = #f = (("sss" ...
<mwette>How do I interpret a variable "#f" with an apparent value?
<janneke>hmm, hard to tell -- but what puzzles me is that clock_gettime, futex and rt_sigprocmask are called all the time
<jcowan>Means that its name is not known for whatever reason
<mwette>jcowan: thanks
<bricewge>Hello Guile!
<bricewge>I have a record name of 33 character long, it's difficult to stay under the line length limit.
<bricewge>I can't remember how to access the field of a record with a shortened name, I thought there was a procedure or a macro to do this...
<RhodiumToad>what kind of record?
<bricewge>RhodiumToad: SRFI-9
<civodul>bricewge: you could always create an alias, like (let ((shr the-very-long-accessor-that-prevents-me-from-remaining-under-the-80-character-limit)) (shr x))
<RhodiumToad>yeah, that's what I was thinking
<civodul>a famous one is (define call/cc call-with-current-continuation)
<civodul>but the tradition in Scheme is long names fully spelled out
<civodul>"code is meant to be read by humans" :-)
<bricewge>civodul: I think that's the one
<bricewge>civodul: I'm defining a mixed-text-file, I find it difficult to keep it readable, fully spelled out and under the 80 character limit
<civodul>how does that relate to mixed-text-file?
<bricewge>Especially with that looonnnng record name
<bricewge>civodul: See in contrast with the nicely formated sddm-configuration-file
***gal is now known as galex-713
<civodul>oh i see
<civodul>here i'd use match-record
<civodul>it matches fields by name, which should be slightly shorter
<bricewge>Thanks, I'll use that then :)
<Aurora_iz_kosmos>Hm, does Guile's bytecode internally transform symbols to be lighter?
<marmulak>hey buddies
<marmulak>does guile code compile to something the os can execute? I found guild compile, but it seems to only produce bytecode
<Aurora_iz_kosmos>marmulak: Afaik there's no native compilation yet.
<Aurora_iz_kosmos>Adorable doujin
<marmulak>wrong window?
<Aurora_iz_kosmos>oy blyat
<marmulak>lol cyka
<Aurora_iz_kosmos>(And this is why you use proxies for irc)
<marmulak>we've all had those moments
<RhodiumToad>guile3 does jit
<marmulak>if it's any consolation I didn't open it
<Aurora_iz_kosmos>marmulak: That's for the best.
<marmulak>JIT is great
<marmulak>I think the name "just in time" is misleading though
<marmulak>when the user is waiting for code to run, it's not "in time"
<marmulak>it's more like "a little bit too late compilation"
<Aurora_iz_kosmos>Eh, the code runs through the unoptimized path first. Jumps to compiled alternatives are inserted later.
<Aurora_iz_kosmos>At least that's how JIT generally works.
<jcowan>It's named by analogy to just-in-time manufacturing, which means you keep only a small inventory (but not zero) and order more parts only when you have orders in hand for the finished product.
<jcowan>In addition, JIT compilation results can run faster than AOT compilation when they can take advantage of things like branch postdiction.
<Aurora_iz_kosmos>I think it'd be neat for Guile to be able to generate executable images like SBCL's, doubly so if it could bundle C dependencies like CFFI can do with :static-link
<marmulak>yeah static linking is tight
<Aurora_iz_kosmos>It just facilitates deployments so much.
<marmulak>then we can write cross platform desktop applications in guile
<Aurora_iz_kosmos>Eh, executable formats would have to be accounted for.
<Aurora_iz_kosmos>Even if you vendor all the libs inside a static image, ELF doesn't run on Windows.
<Aurora_iz_kosmos>It might on OSX though.
<marmulak>yeah it'd have to be compiled separately
<jcowan>anyway, deploying apps with multiple files is pretty much a solved problem nowadays, on several different levels
<Aurora_iz_kosmos>Easy example: A person willing to host/run a program on a machine for me but not technical enough to setup a server, nevermind Docker.
<jcowan>OS-specific package or simply tarball, theb
<Aurora_iz_kosmos>I'm not aware of any specific system to create tarballs with mangled library paths other than Guix
<Aurora_iz_kosmos>And last I tried it didn't work on my machines.
<Aurora_iz_kosmos>(Over a year ago though, I guess)
<Aurora_iz_kosmos>Additionally, Debian packaging is annoying. (I wish Debian had something like PKGBUILD)
<str1ngs>WSL can run elf on windows
<Aurora_iz_kosmos>Ah, true. Still not used to that being a thing.
<str1ngs>guile can run as a static binary say if you used scm_boot_guile. and built statically. you would still GUILE paths for modules. so it's not like it cant do what SBCL is doing. just a little more work maybe.
<marmulak>guix seems like a lot of trouble, I couldn't get ocaml to work on it
<str1ngs>plus guile's FFI is top notch IMHO there are manyways to use it. between guile extentsions to FFI directoy and now even GI
<marmulak>what is FFI
<Aurora_iz_kosmos>Foreign-Function Interface
<Aurora_iz_kosmos>marmulak: Allows you to use C & ASM object libraries from Guile. Much like Java's JNI
<Aurora_iz_kosmos>But better.
<marmulak>that's one of the things that interests me most about guile
<marmulak>one thing that confuses me a little bit is that when I read about using guile with C, it was explained like this: "Write your program in C, and then you can extend it with guile", and when I got more familiar with the concept I thought the natural order was the other way around, to write a program in guile and then rewrite or add parts in C where needed
<davexunit>both are possible, but the latter is the recommended option.
<marmulak>it makes sense
<davexunit>I use the FFI to link against C libraries when necessary
<marmulak>there's untapped potential here for game development
<Aurora_iz_kosmos>Was linking Guile lgpl or gpl?
<Aurora_iz_kosmos>If it's the latter, it'd explain a lack of industry adoption.
<marmulak>long ago I contributed to a game project once where most of the game was written in LUA around some core engine written in C/C++
<davexunit>marmulak: that's actually what I spend most of my time doing with guile.
<davexunit>I have a project that is trying to be for guile what love2d is for lua.
<davexunit>still alpha, but works decently at this point.
<marmulak>oh that's nice
<marmulak>just the sort of thing I'm interested in
<marmulak>I've seen a package like this for other languages like haskell
<marmulak>I take it yours is the only one for scheme?
<davexunit>there are some libraries for other schemes out there but this is the only one of its kind for guile.
<jcowan>marmulak: The original idea was to take an existing program in C and add Guile to it to allow user customization, basically Emacs and Elisp style.
<marmulak>davexunit: I love how your project's irc channel is #guile ;)
<marmulak>it's probably out of my league but I was thinking of trying to write an xmpp client in in guile using libstrophe, which is written in C I believe
<mwette>nyacc's FFI Helper can help converting c headers to run in guile:
<Aurora_iz_kosmos>3> The Guile library (libguile) and supporting files are published under the terms of the GNU Lesser General Public License version 3 or later.  | Oh, so it'd be usable.
<jcowan>Many Scheme-related names have a sense of bad behavior: Scheme itself, Guile, Racket, Larceny, Foment, Gauche, Larceny, Heist.
*Aurora_iz_kosmos doesn't mind GPL home projects, but getting work to adopt GPL is not gonna happe
<marmulak>maybe we can give them positive names
<davexunit>btw there is currently a lisp game jam going on:
<Aurora_iz_kosmos>Guile isn't negative though?
<davexunit>most of the entries are typically common lisp or fennel (a lisp that compiles to lua) projects. hopefully this time around there will be at least 1 scheme entry.
<marmulak>oh sweet
<marmulak>davexunit: hopefully they use chickadee
<Aurora_iz_kosmos>Was there a way to make callbacks in Guile for C?
<davexunit>unlikely, but maybe in the future.
<Aurora_iz_kosmos> I love the totally not vague "SBCL: Not all platforms support callbacks." But which ones? :/
<mwette>marmulak: here is a demo file to convert gtk2.h to guile: ; and here is a sample program using it:
<Aurora_iz_kosmos> Oh, it's been supported since a while. Nice.
<mwette>note this is a "helper" because you are programming C semantics in Scheme -- e.g., you will be passing pointers to functions to get return values
<marmulak>ew pointers
<Aurora_iz_kosmos>Can't help it, Lisp machines are rare now. :p
<mwette>marmulak: the intent is for people to write a Scheme layer on top
<manumanumanu>RhodiumToad__: Regarding the bin->hex procedure: what kind of lookup table do you suggest? A full 256-byte one with pairs of (16 . 16)? I am not sure that will be more efficient...
<RhodiumToad__>I've actually been testing one
***RhodiumToad__ is now known as RhodiumToad
<RhodiumToad>however, the performance characteristics are ... strange
<manumanumanu>how come?
<RhodiumToad>what I'm testing is basically a sparse array, a vector of 1760 slots each of which may contain a vector of length 8
<manumanumanu>how is that supposed to work?
<RhodiumToad>take two bytes of input, which if valid must be in the range #x3000 to #x6700, subtract #x3000 and div/mod by 8
<RhodiumToad>if the value is out of range, or the first or second lookup is #f, then the input is invalid, otherwise the byte found is the result
<manumanumanu>Which guile?
<RhodiumToad>currently trying it on 2.2
<manumanumanu>guile didn't fold euclidean division by a factor of 2 into a bit shift until 2.9.something
<RhodiumToad>right, I'm using the bit shifts directly
<manumanumanu>I am not very CS-y, why would that be fast? I don't know how large guile vectors handle cache locality
<RhodiumToad>I made it sparse mostly to save space
<manumanumanu>But what does "weird performance characteristics" mean?
<RhodiumToad>well that turns out to be down to the context in which logand or ash is being called, and whether you use the native names or the srfi-60 names
<manumanumanu>what is faster?
<RhodiumToad>changing (ash x -3) to (arithmetic-shift x -3) induces a huge slowdown, even though the latter is just a re-export of the former
<RhodiumToad>at least I think it is, need to check
<RhodiumToad>ah, it's (define arithmetic-shift ash) in srfi-60.scm
<manumanumanu>did you compare the assembly?
<manumanumanu>RhodiumToad: the disassembly for arithmetic-shift is a lot longer
<manumanumanu>under guile2.9.3
<RhodiumToad>no, I didn't
<marmulak>hey what do I enter into emacs to git it to run the code I'm working on?
<marmulak>maybe I have to define something
<manumanumanu>I have no idea why, but (define (test b) (ash b 2)) produces a lot shorter assembly that the same with srfi-60 arithmetic-shift
<manumanumanu>marmulak: geiser-eval-buffer will evaluate all your code in the buffer if you are running geiser
<marmulak>what is geiser
<RhodiumToad>manumanumanu: sec, let me paste my current version
<marmulak>lte me try
<marmulak>apparently geiser isn't on ELPA
<marmulak>though the site says it is
<marmulak>oh wait I have to add something
<marmulak>it says to add code to package-archives, but I don't have anything like that
<manumanumanu>RhodiumToad: I suspect your bin->hex is fast enough. I had forgotten that I could just do a 16-byte ref! :D
<manumanumanu>RhodiumToad: hex->bin looks fine. Apart from being weird when you use srfi-60, what is wrong with it?
<RhodiumToad>nothing, now?
<manumanumanu>is it fast? :D
<RhodiumToad>in my tests so far about 50% faster than yours
<RhodiumToad>need to test on more data, though
<jcowan>RhodiumToad: Pointer?
<RhodiumToad> <-- current code
<RhodiumToad>probably less portable right now
<marmulak>apparently I can't access melpa o_o
<marmulak>I love how geiser's git repo contains 7702 objects
<marmulak>just the right amount for an emacs mode
<manumanumanu>RhodiumToad: won't compile.... ;;; <unknown-location>: warning: possibly unbound variable `#{\x200b;}#'
<manumanumanu>ah. dpaste did something fonky
<RhodiumToad>yeah, dpaste "raw" isn't really raw right now due to abuse
<RhodiumToad>I'll put it somewhere more friendly when I consider it more final than it is now
<manumanumanu>RhodiumToad: your bin->hex is a shitload faster as well.
<manumanumanu>at least
<RhodiumToad>yeah, 2x was what I saw
<manumanumanu>the change is not so dramatic for hex->bin, but still about 1.5x
<manumanumanu>ok, not quite: 0.25xxx vs 0.30xxx seconds on 22mb of hex
<RhodiumToad>if my estimate is correct, memory usage for chars-hex should be about 20 kbytes?
<manumanumanu>No idea
<manumanumanu>depends on the overhead of guile's vectors
<manumanumanu>1760 pointers to vectors of 8 elements.
<manumanumanu>a vector of 1760 elements pointing to vectors of 8
<manumanumanu>does guile know that we are only storing bytes?
<manumanumanu>probably not
<RhodiumToad>it could be made less by using bytevectors, but that complicates the logic a bit because it'd be unable to store #f
<RhodiumToad>of the 1760 elements, only 64 point to vectors, the rest are #f
<RhodiumToad>hm, this could definitely be improved on
<manumanumanu>RhodiumToad: cool code! I learned something. Would you mind if I steal the bin->hex trick if I link to your library in the source? I don't really understand the whole sparse tree thing. I told John to ask about your code instead :P
<RhodiumToad>don't link to that paste, it's transient
<manumanumanu>well, whenever you release it?
<manumanumanu>you should. converting to and from hex is common enough
<RhodiumToad>you can steal any of that code, just credit me by name (Andrew Gierth) in comments
<manumanumanu>RhodiumToad: the whole optional uppercase thing would be usable, but having support for delimiters would be better :D
<manumanumanu>That is common enough
<manumanumanu>anyway, good night
<dsmith-work>Oooo. Getting closer to finding the jit problems on arm.
<mwette>dsmith-work: go go
<dsmith-work>First prob was thumb->arm "long" calls throuh a "veneer". I think I got that working.
<dsmith-work>Now it's getting farther, but emitting a bad code for a call.
<dsmith-work>Something is editing a relative address incorreclty.
<dsmith-work>Good: 0x74b9441c: 00 f0 1c e8 blx 0x74b94458
<dsmith-work>Baad: 0x74b943ba: 00 f0 49 e8 ; <UNDEFINED> instruction: 0xf000e849
<dsmith-work>The 0x49 in there is odd. Literally.
<dsmith-work>SHould *not* have that lowest bit set
<dsmith-work>The call must be on a 4 byte boundary, not a 2.
<dsmith-work>Stuffing in a NOP makes it happy
*dsmith-work dances
<civodul>woow, good catch dsmith-work!
<dsmith-work>Hmm. Well, 4 of 39 tests failed
<dsmith-work>Illegal instruction
<dsmith-work>FAIL: test-language
<dsmith-work>FAIL: test-fast-slot-ref
<dsmith-work>FAIL: test-use-srfi
<dsmith-work>FAIL: test-pthread-create
<dsmith-work>All "Illegal instrution"
<dsmith-work>But preogress!
<Aurora_iz_kosmos>What's the general recommended RPC mechanism for interaction between say... Guile and a Go daemon?
<dsmith-work>Of course, all tests pass with GUILE_JIT_THRESHOLD=-1
***dsmith-work is now known as dsmith
<dsmith>civodul: How do I run a specific test under gdb? (with uninstalled guile)
<dsmith>It's probbaly not that the call is not on a 4byte alignment.
<dsmith>More likely there is some code that back-patches the offset isn't right.
<civodul>dsmith: for the tests above that are written in C, you can do "./libtool --mode=execute gdb test-suite/..."
<dsmith>civodul: Thanks