Building mlnet for Haiku, some questions

Hi all.
I’ve recently build mlnet for haiku_x86 (gcc-x86). Now I wish to create the hpkg but first I want to fix some problems…
First problem (big problem, in fact): mlnet only can be build if locale are set in english due to a problem with LC_NUMERIC (otherwise ocaml fails to build because the float format)
Second problem: Replace autoseededrandompool with randompool as crypto++ seems to not include the first due to Haiku not having “nrg” support. I’ve no idea what is this, can someone explain it to me?

Despite those 2 and other minor problems mlnet works nicely but only with the web gui. Next thing is try to create a gui… perhaps too much work for a first project? (It’s my first haiku project, I’m a developer and ancient beos user but this is my first attempt to build something in Haiku/BeOS)

1 Like

Please create a PR with your current recipe, let we tinker with them a bit, maybe we can help you here and there.

Btw you can try to build mlpack too on x86, the recipe is 64 bit only currently. Or OpenCV.

Oh, this is not machine learning, is it?

Hi. No, mlnet (mldonkey) it’s a client for kadmila and e2k networks (also others as fasttrack, soulseek… my build only includes kadmila and e2k),

nrg is I guess “native random generator”. The idea is that the kernel should provide some reliable source of random numbers for crypto purposes. Currently we don’t, so the upper layers should not lie about it and pretend that we do, while providing unsafe/predictible numbers instead.

Setting the locale may be done by exporting the environment variables (export locale=C or so in your build script). Does that not work reliably?

Building GUIs with the Haiku API is fun and enjoyable, I think. If mlnet provides a way to access the data you need (REST API? or would you plug code directly into the server?) it shouldn’t be too hard to achieve something.

Thx for the explanation about “nrg”.
The problem with locale is not about build (as you say it could be easily fixed) but could mask a bigger problem. If I try to compile from sources and the float definition is not the one from the language but the one from the locale I’ve a problem.
I.e:
mlnet writes a file with the configuration. If my locale are setted to C then the decimals are “1.1” but if my locale are setted to “es” (i’m from spain) then mlnet tries to write “1,1”. If I’ve a printf in my code “printf(”%1.1f") it’ll print “1.1” or “1,1” if my locale are defined as “C” or “es”. Since here the problem seems pretty “desired comportament” but if I made a cast from float to string then “1.1” it’s not a valid float because locale are setted to “es” and in “es” the decimal separator is “,” and not “.”. The problem is that ocaml should not be affected by the decimal representation of my locale, a float in ocaml must be “1.1” despite the locale settings.

I must investigate more to clarify what is really happening and fill a bug report if appropriate

About GUI: mlnet provides a tcp socket so I’ll go that way. I’ve seen there’s a native socket implementation (BSocket) so I’ll try to build a communication component first and a minimalistic gui (as possible) around it. I think it could be funny

I’ve uploaded it to github
**** link removed *****

In bin/ folder there’s the mlnet executable compiled on a x86 machine with gcc-x86. Download, run, launch webpositive, go to “127.0.0.1;4080” and enjoy.

Please do not share executable files.

It’s not linked here, the link is to my github. Sincerelly and with all my respects, I don’t understand that publish the binary and the sources at my github account could be a problem (mldonkey is gpl, if you’re afraid of any licensing issue)
If I must remove the link then I’ll remove it but it’s hard to understand for me that sharing a link to a project in a development subforum could be a problem or that I must remove an executable of a gpl project published at my personal github account.
Perhaps I must take a read to the forum rules… Sorry for any inconvenience and if I can’t put a link to my github here then I’ll remove it (I’m not going to delete an executable compiled by me and published at my own account)

p.s. link is removed, if after my explanation you see that I’m not breaking any rule then I’ll add it again.

**** EDIT ***
After reading the FAQ and the Terms of Service I don’t see nothing wrong with share a link to a project. Anywise I’ll wait for your response.

Sharing links to sources is great :slight_smile: .
Sharing links to binaries worries us that the binary may be malicious and could attack our unsuspecting users. It is not a problem, except users could then pretend it’s Haiku fault for not properly moderating the forums, apparently.

Also, maybe some people try to promote the official distribution channels for binaries (through HaikuPorts), rather than “let’s install stuff from the forums”. We all were bit too many times by unofficial software with sketchy installation process ruining an installation. The package manager is here to solve that, and we would rather make use of it. AFAIK we didn’t even make this an official part of the TOS in the forums, but people will just remind to include a disclaimer about it when sharing a binary

But if you share your sources, people will happily take care of turning them into an official package.

I’m not native english speaker so perhaps I was misunderstood. I shared the link to the sources but within the sources tree there’s a bin/ folder with the compiled executable.
I’m not going to delete that bin/ folder (if I “need it” I don’t want to compile again and again and github is great as storage drive xD ) so if it’s a problem then I will wait until I’ve a working recipe for haikuports and then I’ll try to publish it there 'cause I can’t publish the sources without also publish the binary (as it’s part of the project)

I have nothing against publishing your work, and i understand you don’t want to rebuild it again, but there is a golden middle-way: create a recipe and let a builder bots do the hard work, and you and other users will find your port in the Depot. This forum-thread will dissapear from the front page, but if it is in the depot with some easy searching one can find it.

Please, understand: currently no encryption used in the Haiku keychain, a malicious binary, or even a bash script can upload it somewhere with all your WLAN passwords and other keys. Nobody want that.

I understand it (as you can see I’ve removed the link at the moment) but the port is in it’s early stages. It works, but I’ve to tune and test well it, and the only reason that I’ve the executable is for my own “comfort” (I develop on my own machine but also test at work, and at work I don’t want to lose time compiling anything). The goals of the project are to include a gui and get the needed changes merged with mldonkey’s main tree so the executable is only there for fast-test purposes and not as a way to distribute it. I develop for linux and I only distribute my work as a package, repositories are the only way to go. Believe me that I understand your points perfectly.

For me it’s a shame to delete the executable but I understand perfectly your reasons. This night I’ll try to make a valid recipe for haikuports and forget to get some “fun with sockets” :wink: and then restore the link to the project here.

Cheers

1 Like