<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>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 <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 <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 <marmulak>I just really wanted to learn functional programming <marmulak>the thought of learning python makes me feel like I'm going back to QBASIC again <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" <Aurora_iz_kosmos>I find Python's one of the least annoying major scripting languages with a decent library ecosystem. <marmulak>btw about scripting with guile, for invoking shell commands I am going to use the (system) function every time, right? <marmulak>as for your suggestion of using a datastructure with offsets, I am not sure I would know how to do that <jcowan>Python is excellent for whiteboard interviews for the reason Aurora_iz_kosmos gives <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 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'm also getting Illegal instruction on a fresh rpi3 Buster install. Guile built from source, default config. ***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) <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 ... http://paste.debian.net/1139447/ - which fals on line 57 as 'expected', and will fal until I manually wrap gtk-list-store-set-value <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? ***wleslie is now known as verte
***verte is now known as wleslie
<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, dsmith-work says: I'm also getting Illegal instruction on a fresh rpi3 Buster install. Guile built from source, default config. <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>i think we might even be able to get reasonable debug info from it as well <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>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 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! <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 <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 only do 1 << slot as a bignum <wingo>thinking there would generally be fewer than 30 or 62 slots <wingo>but apparently that's a terrible assumption :) <civodul>it means performance degrades significantly when you go beyond 60-something slots <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 <wingo>that was my question for you :) <wingo>i.e. wondering how much of guix time was taken by expand vs compile <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 :) <wingo>wleslie: tx for the link, interesting! <civodul>expand time is not significant when compiling gnu/services/mail.scm or something like that <wingo>i mean i know guix has lots of macrology <civodul>right, i can try and get actual figures <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 <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>i guess you would compile the guix module tree using the optimizing compiler and gnu/ with baseline <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 <wingo>so (use-modules (gnu packages foo)) might take longer <alextee[m]>str1ngs: sorry havent used these annotations before <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) <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 <stis>yeah, got a new version of my python clone out <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 <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 hasn't had cause to touch cobol in many years, fortunately <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 <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? <jcowan>Means that its name is not known for whatever reason <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... <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)) <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'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 ***gal is now known as galex-713
<civodul>it matches fields by name, which should be slightly shorter <marmulak>does guile code compile to something the os can execute? I found guild compile, but it seems to only produce bytecode <marmulak>if it's any consolation I didn't open it <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. <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>then we can write cross platform desktop applications in guile <Aurora_iz_kosmos>Even if you vendor all the libs inside a static image, ELF doesn't run on Windows. <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>Additionally, Debian packaging is annoying. (I wish Debian had something like PKGBUILD) <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 <Aurora_iz_kosmos>marmulak: Allows you to use C & ASM object libraries from Guile. Much like Java's JNI <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. <davexunit>I use the FFI to link against C libraries when necessary <marmulak>there's untapped potential here for game development <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. <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 <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 <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. <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 <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__ is now known as RhodiumToad
<RhodiumToad>however, the performance characteristics are ... strange <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 <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>guile didn't fold euclidean division by a factor of 2 into a bit shift until 2.9.something <manumanumanu>I am not very CS-y, why would that be fast? I don't know how large guile vectors handle cache locality <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 <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>ah, it's (define arithmetic-shift ash) in srfi-60.scm <manumanumanu>RhodiumToad: the disassembly for arithmetic-shift is a lot longer <marmulak>hey what do I enter into emacs to git it to run the code I'm working on? <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>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? <marmulak>I love how geiser's git repo contains 7702 objects <manumanumanu>RhodiumToad: won't compile.... ;;; <unknown-location>: warning: possibly unbound variable `#{\x200b;}#' <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>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? <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 <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>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 <dsmith-work>Oooo. Getting closer to finding the jit problems on arm. <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>Baad: 0x74b943ba: 00 f0 49 e8 ; <UNDEFINED> instruction: 0xf000e849 <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/..."