IRC channel logs

<spk121>dsmith-work: the smallest system we still use in new production systems is the ATMEGA128. 4k ram, 128k flash. 16Mhz.

<dsmith-work>spk121: What's it used for?

<spk121>dsmith-work: controlling a cooler

<spk121>They work fine down at -40C.

<spk121>And only $6 US.

<dsmith-work>Yeah, use the right tool for the job

<dsmith-work>Amazing how hard it is for stuff to work in the cold.

<dsmith-work>We needed to make a thing that needed to start at -50C. We were allowed to turn on a heater and warm up internally.

<dsmith-work>So we didn't really start until -40

<spk121>Nice

<dsmith-work>Heh. Had a problem in that when it was really really close to 0C

<dsmith-work>One of the temp sensors was effectivly floating point.

<dsmith-work>Needed to divide by the value shifted by the exponent or something.

<dsmith-work>But right aorund zero, the exponent was enough to shift all my bits away.

<dsmith-work>And so divide by zero. Bam. Reboot! (This on a microchip pic)

<dsmith-work>Heh.

<dsmith-work>We had it in our kitchen freeezer trying to find the problem.

<dsmith-work>Was very embarrasing.

<spk121>Yeah! Engineering.

<amz3>I made a new episode of gnu guile hacking related to gnunet https://youtu.be/21iuE8Udq08

<amz3>in that video I create a small social app on top of gnunet

<amz3>almost 4h long

<janneke>i am changing macro expansion in mes from just in time during eval to a separate initial recursive macro expansion phase

<janneke>this should fix performance

<janneke>doing just in time macro expansion was pretty easy

<spk121>janneke: how are you feeling about mes these days? Is there a direct path to the end?

<janneke>i cannot seem to get past this: http://paste.debian.net/1006141

<janneke>spk121: i'm feeling excited...we're getting so close

<janneke>guile+mescc compiles tcc that can compile gcc-4.7

<janneke>mes+mescc compiles tcc (but that takes >4 days)

<janneke>OriansJ's M2-Planet is inching towards compiling mes and is getting very close

<spk121>Amazing. At last FOSDEM, it sounded theoretically possible but practically impossible.

<amz3>help!

<amz3>I got an error the internet doesn't know about

<amz3>[LWP 7532 exited]

<amz3>[New LWP 7533]

<amz3>Thread 1 "guile" received signal SIGPWR, Power fail/restart.

<amz3>0x00007ffff762eaed in read ()

<amz3> from /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libpthread.so.0

<janneke>spk121: yeah, after a year of very hard work and co-ordination, we're getting real close

<spk121>amz3: that is not uncommon. BDWGC uses SIGPWR internally to trigger events.

<spk121>amz3: you can ignore it

<amz3>spk121: expect it kills my process

<spk121>amz3: then yes, you need help. Sorry I don't have an answer. ;-)

<spk121>janneke: good luck. I'm cheering for you.

<janneke>spk121: thanks!

<spk121>amz3: SIGPWR is associated with bdwgc "stopping the world"/

<spk121>maybe it is a thread thing

<amz3>the funny (sort of) is that I have another crash with gnunet that doesn't crash the same way

<amz3>using the same program

<amz3>the good thing, is that I reproduce both crash all the time

<amz3>I think I am in big troubles

<ArneBab_>dsmith-work: nice that you found it!

<manumanumanu>Can I make the GC automatically free memory I malloc'd by doing something like this, using make-pointer finalizers: ???

<manumanumanu> https://pastebin.com/tm3JHCan

<manumanumanu>I have a feeling casting such a malloc pointer to a bytevector could potentially be risky if the pointer becomes garbage collected...

<manumanumanu>or does pointer->bytevector somehow "save" the pointer?

<manumanumanu>maybe I should just be using a bytevector in the first place instead of mallocing :D

<civodul>manumanumanu: pointer objects can have an associated "finalizer", which can call 'free'

<civodul>see set-pointer-finalizer! & co.

***daviid is now known as Guest32569

IRC channel logs

2018-01-20.log