IRC channel logs

2017-06-27.log

back to list of logs

<nalaginrut>wingo: of course, based on Artanis
<manumanumanu>Morning people!
<ArneBab_>moin manumanumanu
<manumanumanu>ArneBab_: Hey! I'm trying to implement racket's for macros in guile and not allow myself to look at the racket source. It is harder than I thought :) It is fun, but having seen some other racket macro thingies, I don't know what I expected
<manumanumanu>What have you been up to?
<ArneBab_>mostly work and freenet-stuff
<ArneBab_>right now trying to get gcc-2.95.3 to build :)
<ArneBab_>(a colleague says that it was much faster, I want to check that)
<manumanumanu>I have vacation now, so I have time to do lots of programming :)
<wingo>moin
***ft_ is now known as ft
<dsmith-w`>Tuesday Greetings, Guilers
***dsmith-w` is now known as dsmith-work
<avoine>is there a data structure like an hash table but where I can set my own equality function for retriving the key?
<avoine>oh srfi-1 Association Lists can do that, nevermind
<paroneayea>avoine: :)
<paroneayea>avoine: association lists are O(n) of course, but if you're going to allow an arbitrary function to determine equality, you're probably going to get linear access times anyway
<paroneayea>well O(n) access, O(1) to append, so if you're also appending more than you're accessing, or if you have a limited number of items it should be fine :)
<avoine>paroneayea: I'm trying to do a memoize function where the arguments order doesn't matter
<avoine>I think I got it now: http://paste.lisp.org/display/349608
<ijp>weird, the letrec/define-record-type in boot-9 is giving me errors about the way ellipses are used, but I don't see anything wrong with it
<ijp>(not when compiling, when I tried to run it as an example program)
<catern>ah, wingo's article about fibers is excellent! it is a good explanation of... why processes work the way they do! :)
<catern>operating system processes that is
<xieyuheng4500>what is fiber ?
<ijp>a lightweight concurrency library for guile -- https://github.com/wingo/fibers/wiki/Manual
<avoine>oh the article is on the HN front page: https://wingolog.org/archives/2017/06/27/growing-fibers
<ijp>I hate structs, this vtable stuff is so bleh
<ijp>who actually uses these other than guile internally
<xieyuheng4500>cool name!
<xieyuheng4500>like fibration of manifolds and fiber bundles.
<random-nick>ijp: doesn't GOOPS use vtables?
<ijp>I expect so, but goops counts as guile internals
<manumanumanu>(if #t )
<manumanumanu>oops
<janneke>unknown file:1:0: source expression failed to match any pattern in form (if #t)
<amz3>héllo all!
<amz3>wingo: does a erlang backend makes sens?
<ijp>If I've learned anything doing this project, it's that boot-9 is just not nice
<dsmith-w`>"exploding toothpicks". Heh
***dsmith-w` is now known as dsmith-work
<amz3>ijp: it's nice to see things going forward, honestly I am very interested by your work so that my own work can work fully in Guile but I did not manage to the time to look at it (at least not the recent devs)
<amz3>oops, I highlighted wingo but maybe other know the answer
<amz3>like paroneayea, why did you not choose to create a Guile compiler backend for erlang
<ijp>you mean erlang->guile or vice versa?
<amz3>ijp: guile code running on erlang vm
<amz3>ijp: like you do with javascript
<ijp>compilation from cps isn't too bad, but reimplementing the runtime is a lot of work
<paroneayea>amz3: 8sync's design is pretty different than erlang in many places
<paroneayea>if that's what you're talking about
<amz3>paroneayea: ok
<amz3>ijp: what do you by reimplementing the runtime?
<amz3>ijp: do you re-implement the guile runtime in javascript or something ele
<amz3>else*
<ijp>to take one tricky subject: the dynamic stack
<amz3>oh you must be re-implementing C code in guile, right?
<ijp>plus all the basic datatypes, the more complicated ones like structs, figuring out how you are going to link modules, etc. etc.
<ijp>plus how are you going to handle guile's mutable types on top of immutable erlang types?
<ijp>are you going to have a specific process that handles all references to mutable objects
<ijp>then that's going to have communication overhead for a lot of basic functions
<amz3>simply said I would not implement the difficult part like you describe
<amz3>to get started
<amz3>ijp: fwiw, my forward.scm project doesn't use any module system
<amz3>which means I can leave without some features of scheme
<amz3>that maybe a shame, but that is what it is
<amz3>s/leave/live/
<amz3>ijp: so you know erlang..
<amz3>ijp: also forward.scm is purely functional frontend into the browser world
<ijp>I'm not trying to discourage you from writing a scheme->erlang compiler, I just don't think what you are doing would really be "guile"
<amz3>that's somewhat my question from above, what makes sens in terms of implementation extend guile vm to support erlang semantic or use directly the erlang vm
<amz3>TBH, even if the solution was extending guile vm with erlang semantic, I would still need to fiddle with erlang (or lfe (aka. lisp flavored erlang))
<amz3>Or maybe I can try to learn to read papers and implement what's described in it
<daviid>ijp: guile-gnome internals extensively uses vtables
<ijp>weird, my earlier remark about define-record-type seems to have magically fixed itself
<stis>hey guilers!
<catonano>for the very first time my guile-freexl thing has extracted a whole row from a spreadsheet !!
<catonano>I made it read a whole sheet. It's blazingly fast !
<catonano>Good job, Freexl !
<dsmith-work>Whoo!
<catonano>dsmith-work: :-)
<ijp>fun fact: (define-record-type <box> (box x) box? (x unbox set-box!)) has ten fields in its struct
<ArneBab>catonano: cool!
<catonano>ArneBab: :-)
<catonano>it has to be completed so that it can read a whole file, not just a sheet
<catonano>then, I'd like it to recognize datetimes, date, times and return appropriate types
<catonano>currently it just returns strings
<catonano>it distinguishes integers and decimal numbers, but not datetimes, times, dates