tm-exa has quit [Quit: Computer has gone to sleep]
Praetonus has joined #ponylang
tm-exa has joined #ponylang
tm-exa is now known as tm-away
tm-away is now known as tm-exa
lispmeister has joined #ponylang
aturley has joined #ponylang
aturley has quit [Ping timeout: 250 seconds]
lispmeister has quit [Ping timeout: 240 seconds]
lispmeister has joined #ponylang
trapped has joined #ponylang
_andre has joined #ponylang
emancu has quit [Remote host closed the connection]
emancu has joined #ponylang
sblessing has quit [Remote host closed the connection]
nyarumes has joined #ponylang
nyarum has quit [Ping timeout: 265 seconds]
aturley has joined #ponylang
TwoNotes has joined #ponylang
jemc has joined #ponylang
<TwoNotes>
Has anyone built ponyc on an Arch Linux ARM system? Apparantly the packages are arranged differently. Things like "no such file as math.h"
<Praetonus>
TwoNotes: Are you on latest master? Something about math.h was fixed recently
<TwoNotes>
Maybe a couple days old
<TwoNotes>
No wait, it is a copy of an older download. I will refetch
<TwoNotes>
Building for multiple platforms would be easier if the 'build' directory has per-architecture subdirectories
SilverKey has joined #ponylang
SilverKey has quit [Client Quit]
<TwoNotes>
Odd that on ubuntu on arm, gcc accepts an march=armv7 but on Arch is will not accept that. march=armv7-a seems to work
<TwoNotes>
Maybe different gcc versions
<shepheb>
TwoNotes: I have
<TwoNotes>
Built ok, but running it gets this: "error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory". I think that is part of ncurses, which IS installed..
<shepheb>
I haven't tried recently, but guess where I host my IRC sessions
<shepheb>
let me try fetching latest Arch packages and Pony, and see what I get. then we can compare notes.
<shepheb>
which ARM device are you on? (RPi 2 here, ARMv7)
<TwoNotes>
I have an Rpi3. I think that is an armv8, but all the Linux distros seem to be running it in 32-bit mode. uname says armv7l
<TwoNotes>
I found a post somewhere saying that libtinfo is not packaged in ncurses on Arch. I dunno why
<ohir>
TwoNotes: [32bit on arm v8] its due to ram constraints, rpi3 makers did not get it right. 1GB ob 64b arm is less than 512MB on 32bit one
<TwoNotes>
eek
<TwoNotes>
WHen I ran Ubuntu-MATE, everything worked fine though. I switched to Arch because I really needed a headless version.
<ohir>
TwoNotes: I'd need to dig deeper, iirc I saw this explanation somewhere on raspbian list
<TwoNotes>
'top' shows 0.901 GB available (the rest beig video buffer)
<ohir>
TwoNotes: with 64bit minimal Arch?
SilverKey has joined #ponylang
<TwoNotes>
What I downloaded was ArchLinuxARM-rpi-2-latest.tar.gz.
<TwoNotes>
Note the '2' in there
<ohir>
mm
<shepheb>
I wonder how much of the sluggish performance I see sometimes on RasPi2 is the actual computation part, and how much is the sllooooooooooooow microSD disk?
<ohir>
shepheb: try do disk intensive things on ramdisk, you will see for yourself
<ohir>
;)
<shepheb>
I suppose so.
<TwoNotes>
I NFS-mount to my development machine so I am not dealing with the SDcard, but am dealing with the wifi delays
<shepheb>
not sure if that's better or worse...
<shepheb>
ohir: more to the point, is there a transparent write-through ramdisk thing? I don't exactly want to keep my git clone of my projects in RAM...
<ohir>
TwoNotes: try tmpfs. rsync to, compile, edit, rinse, repeat; then rsync fro
<shepheb>
TwoNotes: also, pacman -Qo /usr/lib/libtinfo.so is libtinfo
<ohir>
shepheb: you can bind with mountoptions but it is not a way as it slows down
<TwoNotes>
shepheb, I seem to be missing that file. which package is in it?
<TwoNotes>
is it in
<shepheb>
sorry, I wasn't clear: the package is called libtinfo
<shepheb>
pacman -Qo is "who owns this file"
<ohir>
shepheb: just set your vim backups/run to temp location on not so volatile medium
<shepheb>
ohir: hahaha
<TwoNotes>
"pacman -Ss libtinfo" gives no results. is it in AUR perhaps?
<shepheb>
it just seems like an always-cached-but-writing-in-background filesystem is a good idea. the kernel does some of that anyway, I guess, but it's still slow.
<ohir>
shepheb: better yet buy a decent backup power supply for your rpi
<shepheb>
like a D cell.
<ohir>
shepheb: as rpi is known to permanently damage sd cards if powered off in the write cycle
<TwoNotes>
I have some external disks I could plug into the RPi I suppose. Tho in my experience laptop HDDs in external cases with no fans do not live very long.
<shepheb>
oh, interesting. I didn't know that.
<shepheb>
TwoNotes: ah, that'll be why you're not finding it
<TwoNotes>
I try to minimize writing to the SDcard in any case, to extend life. I even have the system log going to ramdisk
<shepheb>
libtinfo just isn't packaged for Arch, or at least on ARM
<shepheb>
that package was built by me, a few months ago, from the GNU source tarball.
<TwoNotes>
archlinuxarm is this sort of side project, not really done by the mainline arch people.
<shepheb>
I guess I can recommend the same approach to you.
<shepheb>
my ponyc finished building and is running tests right now.
SilverKey has quit [Quit: Halted.]
SilverKey has joined #ponylang
<shepheb>
lol I failed to link some of the tests, probably due to OOM
<shepheb>
anyway, it's building for me.
* ohir
is fighting suse now, why on earth I've got now: collect2: fatal error: cannot find 'ld'
<shepheb>
that's... wow.
<ohir>
seems it lacked gold binutils
<shepheb>
if you can't find the linker, how did you load whatever output that message? lies!
<TwoNotes>
On Arch, just about *everything* is an optional package I guess
<ohir>
shepheb: on my old box I have golds, installing it here helped
<ohir>
don't ask why ;)
aturley has quit [Ping timeout: 250 seconds]
<TwoNotes>
I built my Pony programs just fine on Ubuntu. This must be Arch-specific
* ohir
hates changing workhorse box, but its a high time. So I am trying suse after years on deb based distros
<SeanTAllen>
There seem to be all sorts of problem with Arch. If someone gets it sorted, a PR to update install instructions would be very welcome. And hopefully we'll have nightlies within a month and from there, releases.
<ohir>
SeanTAllen: you can add: '# zypper in binutils-gold' to linux-install:Suse caveats
<SeanTAllen>
ohir: I have no idea what that means, so no. PR it and it will get merged.
<ohir>
SeanTAllen: I'm trying to set up a devel box on Suse just right now, and I am a bit irritated. Somewhat ponyc did not work with their base tools [gcc 5.3.1/ld 2.26.0.20160309-2]
<shepheb>
the sticky bit for Arch is that things are different on ARM and x86.
<shepheb>
I think the latter works fine.
<shepheb>
the newness of GCC and LLVM is part of the trouble too.
<ohir>
SeanTAllen: ponyc is requiring gold linker (thru -fuse-ld=gold cc flag)
<TwoNotes>
Argh, the libtinfo AUR package creates /usr/lib/libtinfo.so.6 but ponyc wants .5. Can I just symlink it?
<TwoNotes>
shepheb, Yesterday I added some words at the end of the README about building on ARM and MIPS
<TwoNotes>
It seems to work with symlinked libtinfo
Applejack_ has joined #ponylang
<Applejack_>
hi, just some questions about binding to gsl library
<darach>
I'll add a load of docs for MIPS once the port is complete. Possibly also ARM thereafter.
<Applejack_>
That has an internal state, using a particular type gsl_rng and a pointer to it
<Applejack_>
I've read the C binding tutorial and I know about addressof, Pointer and the need to create a primitive, but I would need an example of how to do that so that I can groke the whole process
<Applejack_>
I guess that if I know how to deal with that kind of stateful function I'll know how to deal with the whole Gsl
<Applejack_>
I need to bind to Gsl in order to use Pony for scientific computations
<SeanTAllen>
I'd suggest exploring the usage of the C FFI as it exists in standard library.
<Praetonus>
Applejack_: you can look at net/ssl/sslcontext.pony for the general process
<SeanTAllen>
The VUG meeting in a couple weeks also will touch on the C FFI some but probably not specific to your use case.
<jemc>
Applejack_: I've never used gsl, but a quick glance through the docs makes this case seem pretty straightforward - you just need to call @gsl_rng_alloc and capture the result into a local variable, then pass that to your other gsl functions, then later call @gsl_rng_free on it
<jemc>
as for the type to use for a gsl_rng object - you basically have two options
<jemc>
1. use `Pointer[None]`, which roughly equates to a `void *`
aturley has joined #ponylang
<jemc>
2. create a Pony `class` with no fields, then treat that as the type, taking advantage that Pony passes object references as opaque pointers except for field reading - so a class with no fields can be treated like an opaque pointer
<jemc>
the 2nd approach is basically something like declaring `class GslRng`, then later calling `let r = @gsl_rng_alloc[GslRng](...)`
aturley has quit [Ping timeout: 244 seconds]
<Applejack_>
Ok jemc, looks good, I'll fiddle around your suggestion and will come back. And I'll also look at sslcontext.pony for a broader view.
aturley has joined #ponylang
<jemc>
looks like SSLContext takes a hybrid approach to what I listed above - instead of `Pointer[None]` or `GslRng`, it uses something like `Pointer[_GslRng]` where `_GslRng` is declared as a primitive
<jemc>
it seems like this approach was taken because they wanted to define an `SSlContext` class with fields, with one of those fields being the `Pointer[_SSLContext]`
<jemc>
if you don't need any other fields, the class approach I explained above is probably easiest.
pulpfiction has joined #ponylang
aturley has quit [Ping timeout: 244 seconds]
<Applejack_>
great, thanks
Applejack_ has quit [Ping timeout: 250 seconds]
SilverKey has quit [Quit: Halted.]
amclain has joined #ponylang
lispmeister has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tm-exa has quit [Ping timeout: 265 seconds]
tm-exa has joined #ponylang
Praetonus has quit [Quit: Leaving]
aturley has joined #ponylang
tm-exa has quit [Quit: Computer has gone to sleep]
<doublec>
If ponyc took arguments for the parts that are hardcoded to platform would a ponyup be needed?
aturley has quit [Ping timeout: 276 seconds]
<SeanTAllen>
have you done much cross compilation doublec?
<SeanTAllen>
making sure you are linking against the correct libraries for the target and what not, managing all that is the really painful part. so, i'd say yes, a tool like ponyup is needed based on my experience. if you've had success managing cross compilation in the past without such a tool, i'd love to hear how you did it.
<doublec>
SeanTAllen: a little. Mostly with gcc tools.
<SeanTAllen>
i find it to be a generally painful process to get set up so an easy to use tool would imo, be very welcome.
<doublec>
I'm not a fan of downloading prebuilt binaries to do the compilation that rust does
<doublec>
but I recognise others have different priorities to me
SilverKe_ has quit [Quit: Halted.]
SilverKey has joined #ponylang
SilverKey has quit [Client Quit]
tm-exa has joined #ponylang
<doublec>
Idris has a bash backend - we should totally support that