IRC channel logs

<mwette>bms_: select

<mwette>bms_: in section 7.2.2 of guile 2.2 ref man

<bms_>Thanks mwette, that's about what I was thinking.

<plll[m]>amz3: Nothing yet, still figuring out the basics. Interesting, what are some of the various projects?

<lloda>sneek: later tell daviid it's notabug.org/lloda/guile-ffi-cblas

<lloda>sneek: later tell daviid not sure about the interface language, it should be English? no clue really. Looks fine here

<sneek>Will do.

<lloda>sneek: later tell daviid I've cloned the project to github if it helps... gitub.com/lloda/guile-ffi-cblas

<sneek>Got it.

<amz3``>héllo #guile

<rekado>Hi guilers

<rekado>I wonder why “.go” files are so large. Some of the files I have contain a lot of repetitive data and gzip shrinks them dramatically.

<wingo>rekado: 64 kB alignment of sections is part of it for small files; i don't know about large ones tho. upload the file to https://wingolog.org/elf-mapper/ ?

<ArneBab_>rekado: do they maybe use a lot of macros?

<roelj>Is there an easy way to read gzip'ed files in Scheme?

<amz3>wat!

<amz3>I found a bug in my search engine, this needs to be fixed

<amz3>also I abandonned the idea of having everything in the same process

<amz3>for the time being the main process will be used to process queries and to index html fragments

<amz3>ie. the crawler is a separate program

<dustyweb>o/

<amz3>I have all the pieces here and there, it needs to be made together...

<rekado>wingo: ah, section alignment probably explains why gnu/packages/abduco.go is so “large” despite containing only a single variable definition.

<wingo>yeah glibc manages to keep 64kB alignment without shipping files full of zeroes, i will have to look into how they do that

<wingo>but maybe it doesn't matter? not sure

<dustyweb>beep beep

<OrangeShark>hello everyone

<dustyweb>heya wingo

<wingo>heya :)

<wingo>ACTION wifi fading in and out

<dustyweb>do you think it would be possible to tie together guile-gnome and guile-fibers? :)

<dustyweb>I'm trying to figure out if that would mean needing to run on fibers' event loop or gnome's

<dustyweb>iirc gnome has some way to hook into another event loop

<dustyweb>but I can't find it

<wingo>yes

<wingo>i think you would want to use gnome's event loop

<dustyweb>wingo: hm interesting

<wingo>instead of the one from (fibers epoll)

<dustyweb>wingo: ok!

<wingo>fibers doesn't have a pluggable event loop absraction yet

<wingo>but it's getting close i guess

<wingo>given that (fibers scheduler) doesn't know about fibers any more

<dustyweb>wingo: do you think you'll maybe eventually build the event loop abstraction with GOOPS style generics or would you have ye olde pass-in-functions-as-parameters route?

<wingo>i don't know precisely where to put that abstraction barrier tho

<wingo>heh good question, i don't know, i think i would go for something ad-hoc probably, dunno tho

<wingo>probably with guile-gnome you want to limit to the single main thread

<dustyweb>but I guess that main thread's event loop could then communicate safely with other threads on different schedulers?

<wingo>multithreading is possible but you want to start simple i think

<wingo>and certainly gui things only want to be run on the "main thread"

<wingo>i mean from a kernel thread POV

<dustyweb>wingo: btw I ask this because I'm thinking of building an activitypub client in guile that's able to reuse a lot of the other 8sync'y components I've built

<wingo>i think the eventual answer is yes but i would ask that question later on

<dustyweb>wingo: also also btw I've been working more with Mark S. Miller and I think I can make 8sync more ocap-like / similar to E

<wingo>the glib mainloop is threadsafe but gtk is not

<dustyweb>it turns out it is already very similar

<wingo>nice!

<dustyweb>obviously it wouldn't be "protected" within the same process unless you spawned some code in a sandbox

<dustyweb>but you could do the across multiple processes / machines and preserve some ocap safety

<dustyweb>well, preserve all ocap safety there

<dustyweb>the most interesting thing though of all this that I've been thinking about a lot

<dustyweb>is distributed GC :O

<dustyweb>wingo: have you read: https://marc.info/?l=e-lang&m=97564103120456&w=2

<dustyweb>one of the more delightful things I've read recently

<dustyweb>I'm pretty sure I can get distributed acyclic garbage collection to work across hives/vats (by the different vats paying attention to who's still holding on to a reference) which would allow for a lot more one-off spawning of actors without needing to more manually manage their shutdown (effectively manual memory management, a true pain... CSP also has this pain!)

<dustyweb>but not cyclic

<dustyweb> http://www.crockford.com/ec/dgc.html distributed cyclic GC works and has been done in E and can be layered on top of an existing GC... but it requires that you know which objects are "rooted", and I don't think we can get that info from our GC in guile

<lloda-home>hi daviid

<daviid>hi lloda-home

<sneek>Welcome back daviid, you have 3 messages.

<sneek>daviid, lloda says: it's notabug.org/lloda/guile-ffi-cblas

<sneek>daviid, lloda says: not sure about the interface language, it should be English? no clue really. Looks fine here

<sneek>daviid, lloda says: I've cloned the project to github if it helps... gitub.com/lloda/guile-ffi-cblas

<daviid>lloda-home: ah! i don't like github, but do you maintain both? can I trust the notabug version or you're now only working on github?

<lloda-home>yes, I push to both

<lloda-home>use the one you prefer

<lloda-home>they should always have the same revision

<daviid>dustyweb: you should look/study guile-a-sync2, which has a (very good) integrated loop with the glib one... I've used it to grab info from the filesystem while playing with actors in clutter ...

<daviid>lloda-home: perfect, i'll stick to the notabug then, thanks. I haven't tried to really use it yet, but I'll like to... one of the things that 'scares me' :), to make guile-cv depending on it, is that it does not seems to be a real project (fully autotool chained, with realeses and doc ...), do you have any plan on this?

<daviid>wrt to the language, maybe it's because I use tor-browser... don't know

<daviid>but here the iteface is polish or another east country language ... :)

<dustyweb>daviid: ah right, I remember them mentioning that

<ArneBab_>daviid: if you use tor, then this is to be expected: the website thinks you’re from the country of the outproxy :)

<daviid>ArneBab_: ok, i thought so, too bad i can force english everywhere

<ArneBab_>if you do then you reduce your anonymity (I would guess by factor 5 or so)

<daviid>dustyweb: guile-a-sync2 is extremely well maintained and has doc ...

<daviid>dustyweb: and I'm pretty sure chris uses it for 'real projects', so it is very well tested to, not just a test suite ...

<daviid>dustyweb: then to confirm what wingo told you earlier, you'd have to build a loop (8sync loop) based on the glib loop, nothing else would ever work...

<lloda-home>daviid: it wasn't in my plans tbh (I had no plans). It was meant to be something you'd copy into your project.

<daviid>ok

<lloda-home>I can give it a shot over time, but it won't happen at once

<lloda-home>although seeing the field (everything is outdated...), it would really be good to have standard bindings to the important libraries :-/

<daviid>lloda-home: fine, now I know ... the first step would be AND, OR, XOR, do you have those bindings? does cbals have these on f32, considering 'discrete' float values

<daviid>oh, it is outdated? i though cblas api very stable

<lloda-home>oh, not cblas, but the other Guile bindings you can find out there

<lloda-home>I mean cblas is outdated, but it's outdated forever, so to speak :-D

<daviid>lloda-home: ah, what library do you recommend?

<lloda-home>I don't think map-AND/OR/XOR exist in BLAS at all

<lloda-home>those are not linear-algebra ops

<daviid>ok, i'll rewrite those in C then

<lloda-home>I don't know the full function list by heart, so someone might correct me

<lloda-home>I like BLIS, it's more modern and easier to interface with, but the packaging story is not good unfortunately

<delmarre>speaking of linear algebra

<lloda-home>I think using BLAS is fine

<delmarre>can someone help me with something really simple lol

<daviid>the scheme version I have for these are 'beautifull', and ok with small images, but too slow for real projects ... till we have guile-3 ...

<daviid>I actually don't understand why processing a f32vector, f64 and s32 in scheme is so much slower then in C, I wish I understand, why a simple loop over multi million cells is about 4x to 10x slower then doing the same in C (my ultra simple benchmark), I wish I understand

<lloda-home>f32 etc are slower in Scheme than using #t, actually

<lloda-home>Guile just has to do a lot of translation back and forth between types

<daviid>lloda-home: but you write a loop, that does nothing but i++, it already is an order of mag slower

<daviid>let say you write a f32 mean, it does not have to convert anything does it?

<lloda-home>well the example I was going to give is with array-map!

<lloda-home>it's a C function so if you pass it a Scheme function

<daviid>lloda-home: I don't use array

<daviid>but f32vectors

<lloda-home>well, that should be better

<lloda-home>because the compiler could know that the operands to your function are f32s

<daviid>yes, but it still is much slower, and even before guile-3.0, i wish it be faster

<lloda-home>but I think it only uses that info for certain functions

<lloda-home>if you call anything else, then the f32 has to be converted to a Scheme number etc...

<daviid>I thought the f32vector cells did contain float that were scheme floats

<daviid>that explains a ot then

<daviid>so in the mean example, it will convert multi million float fro C to scheme?

<lloda-home>f32 contains raw floats, but Scheme doesn't use those (but there was this talk about nan boxing a while ago; I didn't follow that)

<lloda-home>daviid: I think so

<daviid>i think davexunit worked on this for f64

<daviid>anyway, I'm happy to rewrite a few snipset in C, till we have those as fast as ... the memory allocation and management is on the scheme side, so I'm happy to do this way till we have a fast compiler for f32, f64 and s32

<daviid>lloda-home: frim guile-ffi-cblas i'd need ADD SUBTRACT DOR product and matrix ops

<daviid>DOT, not dor

<daviid>:)

<lloda-home>daviid: dot is already there (in various forms)

<lloda-home>you can see the full function list here http://www.netlib.org/blas/

<lloda-home>(look down for LEVEL 1)

<daviid>why did you use so many macros? as opposed to 'normal' bindings? it confuses me :)

<daviid>lloda-home: ok thanks

<lloda-home>to avoid repeating code

<lloda-home>not all of those functions are wrapped in guile-ffi-cblas, only those I needed at the time

<lloda-home>anyway completing the bindings should be easy, if there's interest, anyway

<daviid>level1 are the so called safe operation right?

<lloda-home>no

<daviid>ACTION has to read more about cblas

<lloda-home>I shouldn't have used the word level in the README

<lloda-home>in BLAS, level 1 2 3 mean 1: vector-vector, 2: matrix-vector and 3: matrix-matrix

<daviid>ah ok

<lloda-home>I'll make a note to use other words

<lloda-home>you can see there are no map-add or map-substract ops

<daviid>in guile-cv matrix are vectors

<lloda-home>and you carry the sizes on the side?

<daviid>yes

<lloda-home>well Guile has an array type, so I don't understand why no one uses it :-(

<daviid>lloda-home: because i use Vigra

<lloda-home>I'm not familiar, but it in the reference it lists multidimensional array types

<lloda-home>you could use those directly from Guile

<daviid>i mean guile-cv is based upon vigra (it already has a lot more then just vigra, but of course it shares the data representation with Vigra...) which als has linear algebra but not wrapped by vigra_c (and I nwanted to write these myself to get my basic math back :)

<daviid>there terminology is terrible

<lloda-home>it says it has a numpy interface, and numpy's arrays are basically the same as Guile's

<daviid>in vigra an image channel is always a f32vector, there is no other channel type

<daviid>in vigra the caller allocates, which is why I picked up vigra (among othe reasons)

<lloda-home>I was looking at http://ukoethe.github.io/vigra/doc-release/vigra/index.html

<daviid>this choice, f32vector for channels, is the best choice ever, and a perfect compromise between speed for computation and precision wrt 'vision'

<daviid>like any java doc, C++ doc is unreadable

<daviid>these guys call a vector array, and multidimensionsl array a list of vectors ...

<daviid>then the doc is for c++ devel only, unless you know what ou're lokkibg for, you don't find anything :), just terrible, there is not even a 'concept' index

<daviid>anyway, you can look at the guile-cv doc

<lloda-home>daviid: ok I'll have a look.

<daviid>a couple of order of magnitude better :), (always to be improved of course, but quite good already

<daviid>lloda-home: guile-cv depends on vigra_c (as you know, we dont have ways to bind c++ lib), that is were i know how things are done, what binding i can start with ... and i chat with its author aalmost everyday, he did change a lot of thigs for me already ...

<lloda-home>daviid: is that BSeppke?

<daviid>java doc does not even list its first aegument... it's like hmanity losts its mind :)

<daviid>the zeromemq author recently wrote he should never have choose C++, and rewrote the project i pure C code

<lloda-home>hehe, I do C++, so I dunno

<lloda-home>but I know you can do multidimensional arrays in C... FFTW is the best example, it's just perfect

<lloda-home>so this isn't really a C++ vs C thing

<lloda-home>anyway, I'll have a look and I'll also have a look at autotooling guile-ffi-cblas, if that'll help

<daviid>lloda-home: the documentation of C++ projects I had to read is terrible

<daviid>unlike C doc, with an API ... a list of functions ...

<daviid>because their authors think you know their class, subclass ...

<lloda-home>ah, I can see how that can happen

<daviid>so many times i look for somtheing in vigra, it is not in the list of class not in the list of functions ... no concept index .. then i ask benjamin (the vigra_c) aythor, and find out the name is not even standard image processing names ...

<ArneBab_>daviid: is aythor an experienced image processing professional/researcher?

<daviid>in vigra_c, (I already told him it was not a good idea but...) every variable that are f32vector in and out, are called arrays, arr_in, arr_out ...

<daviid>ArneBab_: yes, the vigra author is very knowledgeable and a respected pro in image processing

<daviid>just like they call vectors arrays, some young people think they have to 'rename' things ... the C++ Vigra manual is full of buz names, and 'false' complexity

<daviid>C++ code is generally unradable, full of false an totally unecessary complexity, in my not so humble opinion

<daviid>anyway, back to work

<daviid>lloda-home: will try as i find time, maybe i write these myself in C, I'm a bit scare to depend on a project your are nt actively following ...

<daviid>but then my not so humble opinion is backed up by the zeromemq author, who i do respect a lot

<daviid>i wish i had the url of the article i red aboyt htis

<daviid>is it nanomemq maybe?

<daviid>wingo: would know I guess

<wingo>ACTION dunno :) good evening tho :)

<daviid>good evening wingo

<lloda-home>daviid: it's just that I put in it what I needed for myself. If you don't see much movement in the project, it's because you're the first one to ask me about it (!)

<daviid>lloda-home: sure I understand

<daviid>ArneBab_: I would not have based guile-cv on vigra if I did not think its author was extremely knowledgeable in the field, and if I would not beleive it was there for good and for long ... though as I said earlier, guile-cv is (a lot) more then just vigra ...

<daviid>ah nanomsg

<daviid> http://nanomsg.org/documentation-zeromq.html

<daviid>the article i was refering to is this one: http://250bpm.com/blog:4

<daviid>Why should I have written ZeroMQ in C, not C++ (part I)

<daviid>every C++ devloper on the planet should read this :)

<daviid>twice

<daviid>vigra should have been written in C, image processing does not need template :), it needs fast and GPU based linear algebra

<daviid>lloda-home: does cblas uses GPU?

<lloda-home>daviid: there are many implementations of cblas, all share the same interface

<lloda-home>there's cublas from nvidia, and clblas, and vienna-cl, etc.

<lloda-home>in guile-ffi-cblas you can pass in an env variable the one you one to link with

<lloda-home>actually this dependency handling is something that I had doubts about

<lloda-home>for a standalone package that needs some BLAS to be installed

<daviid>lloda-home: very nice, so i really should try hard to use your work, then install GPU blas...

<daviid>i reaaly have to study a bit more about this, thanks lloda-home

<lloda-home>daviid: yw, I'll be around :-)

<daviid>do you have min, max and range bindings for f32?

<daviid>lloda-home: guile-cv doc is here one of the quiz I had in mind also is: in guile-cv, these ops accept any number of images

<daviid>oh bad paste

<daviid> https://www.gnu.org/software/guile-cv/manual/html_node/index.html

<lloda-home>daviid: BLAS only has index of max of abs value

<daviid>lloda-home: no min? and why abs?

<lloda-home>because those are the things you need in linear algebra programs I suppose

<lloda-home>to compute norm-1, norm-inf, etc

<lloda-home>of vectors

<delmarre>do you guys have a preferred way to share code for help with debugging?

<daviid>lloda-home: image data structure is described here 3.2.1 Image Structure and Accessors (it will take you just a few minutes to read this, it is dead easy and dead simple)

<delmarre>because i am fucked

<delmarre>and need some help haha

<delmarre>trying to calculate winding numbers

<delmarre>and can't find what i'm doing wrong

<daviid>lloda-home: so, i can not find the min value of a f32 vector in cblas?

<lloda-home>daviid: cblas doesn't have a function for that

<daviid>ok

<daviid>lloda-home: another thing i wanted to ask is in guile-cv, like in scheme, all these linear algrbra proceures accept any number of images

<lloda-home>daviid: yeah it's nice to be able to use match like that (match image ((width height ...)))

<lloda-home>match comes from upstream without many changes so it doesn't support arrays which are a C-defined type

<lloda-home>that's a defect in match I think

<lloda-home>you can do (match (array-dimensions a) ((...) ...) ) etc of course

<daviid>so i implemented specific f32vector-ops-at-offset, like f32vector-sum-at-ofset ... but then using cblas i'd have to call recursively right?

<lloda-home>daviid: wdym any number of images? like do the same op on many images?

<daviid>yes, like this https://www.gnu.org/software/guile-cv/manual/html_node/Processing.html#im_002dadd

<lloda-home>daviid: if you used arrays you'd just make a view into that offset and pass the view

<lloda-home>I don't understand what you mean by recursively there

<daviid>all linear algebra, including multiplication

<daviid>lloda-home: I can build an array of f32 vectors, and call cblas then

<lloda-home>daviid: so from your link I understand that im-mutiply i1 i2 i3 ... does (i1 * i2 * i3 * ...)?

<daviid>yes

<lloda-home>you'd need to call multiple times into blas for that

<lloda-home>but for example im-add i1 i2 i3... you could do that with a single op if you package the arguements in a certain way

<daviid>yes, in the case of matrix multiply, i also have to compute intermediar results in scheme, but what about imadd

<daviid>im-add

<daviid>lloda-home: right so i have a list of f32vectors, how do i pack for cblas?

<daviid>(I beleive calling cblas multiple time for matrix mulitplcation will be faster the scheme anyway)

<lloda-home>you'd put them one after another in a big f32vector, then tell CBLAS that that's actually a matrix by giving it the right sizes and strides, and then make a vector-matrix product of #(1 1 1 ...) times your matrix

<lloda-home>that'll sum all the rows

<lloda-home>be faster anyway: likely

<daviid>lloda-home: cooking needs a lot of prep in cbals :)

<daviid>cblas

<lloda-home>daviid: I guess that can be true

<lloda-home>cblas is not a general array library, it only has linear algebra primitives, so if you want to do an outer product or something like that, it just isn't there

<daviid>lloda-home: at some point it can be a memory allocation problem too

<lloda-home>yes

<daviid>I think i will rewrite these i C myself

<lloda-home>I see gc warnings all the time myself :-/

<daviid>I do too

<lloda-home>to be clear, blas doesn't allocate anything by itself, ever

<daviid>in real world, images are really big .. copy those channels won't work well

<lloda-home>but yeah, massaging the data into shape for calling can take memory

<daviid>and time too

<sepisoad_>is there a way to get information about a procedure inside repl

<sepisoad_>like to see what are the input parameter/types of a procedure?

<sepisoad_>for example something like this: (help cons)

<lloda-home>daviid: a funny thing is, in Guile you can make constant arrays for free, any size

<lloda-home>like (make-shared-array #0(1) (lambda i '()) 10000000)

<lloda-home>takes no space

<lloda-home>but some version of blas will just hang if you pass zero strides, it's pretty sad

<lloda-home>sepisoad_: just as you just did, it's just cons doesn't have docs

<lloda-home>which is bad...

<lloda-home>e.g. (help string=) will give you that info

<sepisoad_>it was an example

<daviid>lloda-home: have to go afk a bit, bbl, thanks

<lloda-home>daviid: see you around

<sepisoad_>(help open-socket) :-|

<lloda-home>sepisoad_: that function doesn't seem to be exported by any module

<sepisoad_>lloda-home, I was just trying to express what i want

<plll[m]>Hey, how would I find my guile prefix (eg. For installing fibers)?

<plll[m]>Tried with /opt/guile and i cant import it in my repl. Libraries like artanis work fine tho

<OrangeShark>plll[m]: you need to install it in guile's load path

<OrangeShark>or add to guile's load path to find it

<plll[m]>OrangeShark: thanks!

<OrangeShark>plll[m]: usually it the install location of guile like /usr, but you can always add any other directory to GUILE_LOAD_PATH and GUILE_COMPILED_LOAD_PATH

<plll[m]>OrangeShark: /usr works perfectly

<plll[m]>How do people usually go about isolating builds/environments w guile?

<amz3>plll[m]: they use guix

<janneke>yay, mes+nyacc is resurrected!

<amz3>!

<amz3>plll[m]: btw, I found which project I will work on

<janneke>i didn't run nyacc on mes for about almost a year, and mwette has been very busy

<amz3>sure

<amz3>so now, you can run nyacc and compile C?

<amz3>nyacc is only the parser, is that correct?

<janneke>i wouldn't say "only", as the parser is currently *much* bigger than the compiler

<janneke>but yeah...