IRC channel logs


back to list of logs

<happy_gnu[m]>ACTION is not doing anything interesting :/
<ijp>ACTION is writing a classifier, but in python, so ho hum
<daviid>ACTION needs a classifier 'à la octave' for guile-cv
<stis_>coding in python and guile atm, compiling python lookalike code to guile scheme
<daviid>wingo: great work on goops, as usual :). fwiw, I'd make #:metaclass <redefinable-class> the default. users who want to benefit from static slot allocation would then have to ask for it, like #:metaclass <nonredefinable-class> or somethig like that ...
<mwette>looking at liblinear classifier ; ran into issue w/ my FFI helper, but working to fix
<daviid>mwette: cool!
<mwette>I got it to compile. send me an email mwette at
<daviid>mwette: did you upload the code somewhere? have to run, be back in an hour or so
<daviid>i can send an email of course but if the code is upoaded i clone ...
<mwette>not in latest release -- gonna be a while for a new release
<mwette>I'm looking for suckers to try the generated code out. I am having some success though. It seems to be working on cairo. I was planning to send you the linear.scm file and the ffi-helper runtime.
<mwette>oops email is matt.wette at
<daviid>mwette: I have to look if it would fit my needs (it appears it would, though my initial plan was to talk to the octave team to extract 'classify' from the octane-nan package ... but I admit I have little hope this happens, as it would not be easy, because their code is split in between C++ and octave itself ... none that we can reuse 'as is' using our ffi ...)
<daviid>then I thought you were actively working to make a good binding, maintained and documented ... a real project I could rely on ... but I understand you did pick this up to test nyacc and ffi-help ...
<daviid>and I have liited time, but, I'll send an email and try it for you ... the linear.scm is generated no?
<mwette>I have no wish to support liblinear, but linear.scm is 100% auto-generated from linear.h It can support add-on scheme code (just add to the .ffi file)
<daviid>so, if I grab a copy of ffi-help I should would generate it and it would be identical to your ?
<mwette>to run the auto-generator you need the nyacc distribution, because that has the C parser and analysis routines, and ffi-help. To use linear.scm you only need ffi-help-rt.scm, which is the runtime support. Others are using nyacc, for the C parser, via guix.
<mwette>Here is "linear.ffi" which is the input to the autocoder:
<daviid>ok, sent ...
<mwette>(define-ffi-module (ffi linear)
<mwette> #:include '("linear.h")
<mwette> #:library '("linear")
<mwette> )
<daviid>mwette: I'll take the offer not to run the generator then, I'll try your generated binding, thanks (I sent an email ...)
<daviid>mwette: I'm on debian buster, here liblinear is 2.1.9
<daviid>sorry 2.1.0
<daviid>will that work? what is the version yo used to generate the binding?
<mwette>I think mine is linear 2.1.0 as well, but not sure: shows up as "2.01_0" o macports
<mwette>You will also need bytestructures for the struct support.
<daviid>ok, I beleive "2.01_0" is a string bug, and I must already have a clone of bytestructures somewhere (never used it though)
<daviid>* believe
<mwette>So I can see, looking at train.c, that you need to pass pointers to vars. I'm thinking about the double, but parameter is like this:
<mwette>(define param (make-struct-parameter))
<mwette>(define param-bs (fh-object-val param))
<mwette>(bytestructure-set! param-bs 'solver_type 3)
<mwette>(define prob (make-struct-problem))
<mwette>(define prob-bs (fh-object-val prob))
<daviid>mwette: if you can put this in the email, right now I'm on something else and would not be able to concentrate 'to be with you' ...
<mwette>daviid: sent email -- I have issue. not easy to pass pointer-to double right now (but pointer-to struct is OK). I need to gen some macros to be able to declare a double and get it's value after passing it as (pointer-to double-var)
<daviid>mwette: ok thanks. don't spend too much time on this 'for me', I'm not sure I will use it 'seriously' ... but tx again
<daviid>mwette: I see they have python and python3 bindings by the authors, may be some ideas to snarf from there ...
<mwette>daviid: Thanks. I'm not looking to make a custom interface. I may play with it to see if train.c can be converted.
<daviid>mwette: it's ok, if I go down that route I'll
<daviid>I would write a 'proper binding' anyway
<mwette>daviid: got it
<daviid>but that is uncertain really ... and before anything else I will try to evauate the results I could reach using this lib using their liblinear-tools (command line ...)
<daviid>liblinear-train and liblinear-predict ...
<dustyweb>wingo: btw I've thought about it and I agree with daviid and davexunit that the <redefinable-class> metaclass is a good default, and that "ossifying" should be more done explicitly with GOOPS
<dustyweb>davexunit: I've got a nice canonical-sexp parser, and I built it by studying the ice-9 json stuff
<dustyweb>thanks again for that work :)
<ArneBab_>seeing a natural language paper fail in the introduction: "As a rule, implementations of recursive functions are slower than those of iterative because recursive functions must allocate memory for their multiple instances." → — tail recursion strikes
<janneke>ArneBab_: for some popular programming languages that may seem pretty true?
<ArneBab_>janneke: yes, but that does not make it into a good base to discuss general cognition: If Scheme can do tail recursion, why should our brain not be able to?
<ArneBab_>amz3: lispyscript has a generic solution to add TCO to JS:
<ArneBab_>amz3: just wrap every function definiton in tco(function(…){…};) and our JS should work in all browsers.
<ArneBab_>(not yet tested)
<ArneBab_>ijp: see above ^ (fix missing TCO)
<ArneBab_>and it’s surreal to see the name Gozala there — the one who wrote the other wisp ☺
<ArneBab_>the world of specialist knowledge is a village
<ArneBab_>(other than failing at that rule, the paper seems interesting till now)
<dustyweb>how expensive is the set-port-encoding! procedure?
<dustyweb>I currently have read-csexp and write-csexp both call it on every invocation
<dustyweb>but maybe that's unnecessary, I'm not sure.
<dustyweb>canonical s-exps library seems to be able to parse ~50k messages per second on this naive implementation on this decade old machine
<dustyweb>seems pretty good
<happy_gnu[m]>dustyweb: thats a lot :O
<ArneBab_>dustyweb: nice!
***vicenteH` is now known as vicenteH