***logicmoo is now known as dmilez_
***dmilez_ is now known as dmiles[m]
<jeko>Do you know how I can clear the report between test runs with SRFI-64 ? <jeko>what do you mean by "make clean" ? <amz3>if you project has a Makefile with the 'clean' rule you can maybe use 'make clean' to remove the files generated by the test runner <amz3>otherwie you can use 'git clean -fxd' with care <amz3>the above will delete all files not tracked by git, including ignored files <amz3>lookup the definition of -f -x and -d in the git man page <jeko>What if I don't have any file created ? I have a basic scheme file I can (load "main-test.scm") to see if all my tests are OK <jeko>I load it each time I make a change in main.scm <jeko>(I try to setup a TDD workflow haha) <jeko>I load the test file into my geiser REPL <jeko>It is like the REPL keep a variable which is used each time I run my tests <amz3>then IDK, maybe some else will, otherwise send a mail on the mailing list <jeko>alright thank you for trying ! <rekado>in order to determine the text width for the picture language: I guess I could use freetype directly. That would be much lighter than using Cairo. <civodul>are you implementing the picture language in Guile? <rekado>just ,use (pict) and then try something like (circle 10) in geiser. <rekado>I haven’t implemented rotation or translation yet. <rekado>This all sits on top of bare SVG, which is built with SXML expressions. <rekado>all of the composition procedures already work fine. <civodul>and geiser already does the right thing <rekado>(apply vc-append (map circle (iota 10))) <civodul>well i need: (apply vc-append (map (cut circle <> #:border-color "red") (iota 10))) <civodul>because i have a black background :-) <rekado>you could also use colorize: (apply vc-append (map (compose (cut colorize <> "red") circle) (iota 10))) <civodul>FP and layout go together really well <rekado>geiser image support is a dirty hack: geiser supports #<Image: /path/to/image>, so in the record-type-printer I first save the SVG to a temp file and then print out #<Image: /path/to/the.svg> <miqlas>I'm on my way to get Guile working on Haiku. It is already compiled, but some test failing. Lemme grab the test output <miqlas>Any help would be really appreciated. <spk121>miqlas: porting Guile is not easy. I made it work 99.9% on Cygwin but I gave up on the last 0.1% <miqlas>have to say, we have an really new boemgc port, maybe there lurking also some problems... <miqlas>spk121: still would be great to have it, as libfive requires Guile <spk121>miqlas: the out of memory error is not very portable. For some OS's we just disable. <miqlas>Hmmm.. I'm not sure where or what triggering it, have to examine a bit better <spk121>miqlas: actually test causes out of memory errors on purpose to see if it can recover from them gracefully <spk121>it relies on having a working 'setrlimits' procedure, which many OS's don't: hurd, darwin, cygwin, for example <miqlas>lemme check if we got 'setrlimits' or not <miqlas>spk121: i got only setrlimit, but no setrlimits <miqlas>yep, config.h tells: #define HAVE_SETRLIMIT 1 <miqlas>and the symbol is in our libroot (hyper-super-mega-lib with things like threading and stuff) <miqlas>if something in libroot, then it is OS provided. <miqlas>but if we got setrlimit, then the out of memory should not happen, right? <miqlas>libffi test also broken. I checked, we got the current ffi port, and it is used on myy system. <miqlas>other failed test is the posix regex: i'm not sure about it. We are more-or-less posix compilant. <spk121>No, the out of memory stuff is happening on purpose. But the test should recover more gracefully. <miqlas>spk121: more examination required then, i suppose. <spk121>I wouldn't get hung up on it. The test is already disabled for many systems. <miqlas>as i told, our bgc port is pretty new, made by one bgc maintainer, so technically it should be ok, but it haven't got enough testing yet, hard to say it is mission-ready. What do you think, could it be the culprint? <miqlas>my main problem is: i built guile with ncurses, but if i try to run a helloworld program, it complains : there is no ncurses <miqlas>btw: i have absolutely no idea about guile, never used it before, so maybe i do something wrong. <spk121>Haha. guile-ncurses. Now you have real problems. Its maintainer is an idiot. (lol. It is me) <miqlas>spk121: can you please forward my message to the guile-ncurses maintainer? He is a great man, and i think he does an exceptionally good job, but somehow (I'm absolutely sure it is because my sillyness) i can't get it work. <miqlas>spk121: i have to go now, i'll come back later <miqlas>spk121: any idea, why the ncurses module missing? <miqlas>is there anything i can do? I already tried to define readline too in my recipe, and AFAIK readline and ncurses are "synonym" things, one should use one or the other but not booth. <spk121>miqlas: I can walk you through it now, if you like. <miqlas>i have time, but i got some beers already, so let's try t :) <spk121>first, let's see where Guile thinks files should be stored. Try "guile -c '(display %load-path)'" <miqlas>(/packages/guile-2.2.3-1/.self/data/guile/2.2 /packages/guile-2.2.3-1/.self/data/guile/site/2.2 /packages/guile-2.2.3-1/.self/data/guile/site /packages/guile-2.2.3-1/.self/data/guile) <spk121>OK. guile-ncurses tries to install itself into the site/2.2 directory. Is there an ncurses subdirectory there, or in any of those places? <miqlas>the path : /packages/PACKAGENAME-VERSION/.self/ = / <miqlas>so "/packages/guile-2.2.3-1/.self/data" == /system/data <miqlas>it is because the package management, do not care about it. <miqlas>so everything installed into /packages/guile-2.2.3-1/.self/bin is accesible in /system/bin, which is in the PATH <spk121>ok. but I think the question is if ncurses installed itself into the right directory, which would be one inyour %load-path <miqlas>in the folder /boot/system/data/guile i have only a subdir called "2.2", but no site <miqlas>spk121: ncurses installed with the devel package. So it is complete. <spk121>did you build guile-ncures from source? <miqlas>spk121: isnt it in the official guile tarball? <miqlas>spk121: umm.. do you mean, i have to install extra modules to get an hello world working??? <miqlas>if so, then i understand everything. <spk121>Nah. I mean, the plain Guile version of hello world is just (display "hello world\\n") and you don't need guile-ncurses to run plain guile. But if you want to do text user interfaces the ncurses way, it is a separate tarball that you have to download and build <miqlas>spk121: you know, i went to google with this keywords: "guile hello world" <miqlas>found a source code, tried to run it: ERROR <miqlas>what should i think in this case? <miqlas>ok, now it makes sense, ncurses is a separate module, but as guile searched for it during the configure, i tought it will be automatically recognized and built <miqlas>Let me give you my postal address to send me the nobel peace prise. <miqlas>ok, but guile can more than hello. And the tests shows it is broken. <miqlas>spk121: thanks for helping to debug this strange bug. :) <miqlas>amz3: are you from the nobel award team? <spk121>it is a bug in Google. I'll call Mark Zukerburg and let him know. <miqlas>spk121: and call JLG too, please. <miqlas>Jean Louis Gassée == owner of Be Inc. <miqlas>spk121: i have to say, you gave extraordinary help to debug this hello world problem. I would give you a star or like now. Thanks. <miqlas>now we know, the basic IO is ok. <miqlas>I know almost nothing about guile. is it possible to build an executable from a guile source? I mean can i build an elf binary from this guile script somehow? <miqlas>guild made a hello.go file from my hello program. <miqlas>But i cannot run it. It is an executable? Or smething else? <miqlas>file says: ELF 64-bit LSB shared object, no machine, version 1 (embedded), dynamically linked, with debug_info, not stripped <spk121>miqlas: It won't compile down to elf, yet. That feature should land in 3.2. <miqlas>and btw, why it is .go? why not .gu? <spk121>.go is more like java bytecode. It is an intermediate representation between source and ELF. <miqlas>our runtime loader cannot handle it. so it can be elf, but not runnable. <miqlas>so according my google fu, yet the hello world requires (sometimes) external modules. Can you tell me which are the most important modules? I have to port them too to make guile usable on Haiku. <miqlas>checked the debian recipes, but it wasn't enough info. <miqlas>i already got the little schemer as pdf, i pretty like the pictures but no idea about scheme. Is guile a complete scheme interpreter? <miqlas>Sorry, i have abslutely no idea about it. <miqlas>It is just a dependecy to one thing what i have to have <civodul>miqlas: it's ELF containing Guile bytecode <miqlas>btw: hello from the HaikuPorts team. <spk121>miqlas: it is pretty complete standalone implementation. GUI stuff, database stuff, games stuff and some web framework stuff isn't included. <miqlas>I'm responsible for the mathematical libs, like blas and some strange stuffs like blender, opencv, vim, emacs, r, fortran, and for some libs for haiku <miqlas>spk121: what kind of gui toolkit does guile use? <spk121>Well, the GTK2 port is mostly complete, as far as I know. But it has some problems. <spk121>I'd say our GTK3 story is kind of stalled in pre-alpha. No QT work as far as I know. <spk121>And I haven't tried it, but I think SDL works. <miqlas>we got an almost complete Qt implementation, hovewer GL is still missing, but no GTK <miqlas>is it also suported trough an external module like ncrses or is it in the main lib? <spk121>Cool. I should do paid work now. Good luck! <miqlas>and it follows yor mouse cursor! <miqlas>and you can install it onto your desktop as a replicant <miqlas>OrangeShark, the 's/linux/haikug', thanks