<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 <mwette>I got it to compile. send me an email mwette at gmail.com <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 gmail.com <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>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>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) <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 <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 <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: just wrap every function definiton in tco(function(…){…};) and our JS should work in all browsers. <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 ***vicenteH` is now known as vicenteH