<kyak>
viric: gdbserver is working here. kind of... i didn't try flashing the image to Ben, it's too big
<wolfspraul>
kyak: why is it so big?
<kyak>
wolfspraul: it was not a minimal image, it has stardict + dependencies
<kyak>
but it's still bigger than usual, of course
<kyak>
it is not stripped
<wolfspraul>
roh: you there? about tolerances of the connectors on Milkymist One...
<wolfspraul>
the ones you need to watch out for are: DC jack, line-in/line-out, and vga
<wolfspraul>
in that order
<wolfspraul>
the DC jack is pretty bad, because there was a back and forth about which vendor etc. so the footprint and connector do not provide a very tight connection
<wolfspraul>
what you can try is on your mechanical sample, you unsolder the DC jack, then you see the tolerance yourself
<wolfspraul>
I think for the DC jack, you need at least 1mm tolerance on each side
<wolfspraul>
the DC jack on your mechanical sample is the same as the one used on rc2
<wolfspraul>
after the DC jack, the next 'worst' are probably line-in/line-out, and then vga
<wolfspraul>
all others should have fairly small tolerances because the PCB holes are holding them quite tightly in place
<viric>
kyak: what dependencies may have stardict?
<viric>
isn't it like dict?
<viric>
kyak: I still don't have a cross-build gcc in the nanonote though :)
<kyak>
viric: gtk2, for starters
<viric>
ah.
<kristianpaul>
sure gtk2 is not tooo slow?
<kristianpaul>
for ben as was for freerunner etc..
<viric>
why would someone want stardict and not dict?
<kristianpaul>
dics
<kristianpaul>
i guess
<kristianpaul>
can you compare dic size in both?
<viric>
I don't know dics
<viric>
I only use dict.
<kristianpaul>
dictionary i meant
<viric>
I never used stardict
<kristianpaul>
also StarDict hav translation capabillites
<kristianpaul>
ahh
<kristianpaul>
is good
<viric>
but 'dict' has many clients, among others, console clients
<kristianpaul>
well i compared with gnudict in jlime
<viric>
dict.org  I use
<kristianpaul>
he talking about startdict we can set it as default start and make look the ben as a dictionary again ;)
<viric>
.
<viric>
:)
<kristianpaul>
ha who needs a EMC, lets do wirinng :)
<juan64bits>
is an basic example.. using the diafgram bloack for read ADC data and show over frame buffer
<juan64bits>
*diagram blocks
<kristianpaul>
yes but how it look? anyway i'll ty thhe code later i must leave
<kristianpaul>
:(
<kristianpaul>
look i meant bacause the refresh
<viric>
I managed to run 'gcc' in the nanonote
<viric>
It's super slow
<viric>
When the RTC forgets the time?
<viric>
removing the battery?
<viric>
tries to build fossil in the nanonote
<viric>
uhm missing zlib. bad try.
<kyak>
yes, gcc is pretty slow
<viric>
Is there any other option, to compile, let's say, C code?
<viric>
kyak: I just sent a benchmark to the mailing list.
<kyak>
thereis a picoc
<kyak>
it's a c-code interpreter
<kyak>
pretty small and fast
<bartbes>
or tinycc
<kyak>
viric: benchmark - interesting, i'll have a look
<viric>
tinycc builds for mips!?
<viric>
I mean... tinycc is the 'tcc', isn't it?
<bartbes>
oh, no
<bartbes>
I guess not
<viric>
kyak: an interpreter is not a compiler :)
<viric>
kyak: sorry. I wanted a compiler simply.
<kyak>
sure, sure...
<kyak>
it doesn't really matter in case of Ben
<kyak>
the only use case i see is compiling on the go
<viric>
on the go?
<viric>
GB> B0:>5 on the go? :)
<kyak>
and it doesn't matter whether it is interpreter or compiler
<viric>
?> ?CB8?
<kyak>
2 ?CB8 )
<viric>
:)
<viric>
?>?@>1C9 openssl speed 2> B2>Q<
<kyak>
in fact, i didn't find a lot of use for gcc in Ben
<viric>
neither I
<viric>
I thought it could help me learning mips assembly.
<kyak>
i got dissappointed when it didn't compile linux kernel (not enough memory)
<kyak>
:)
<viric>
(not specifically the instructions, but how the common operations work)
<viric>
lack of memory is a big issue there. Big nand, not bad cpu, slow nand, little memory
<kyak>
agree
<viric>
We are too used to abuse memory lately, though.
<viric>
640KiB should be enough. :)
<kyak>
adding swap is not very helpful, it is very slow
<kyak>
i heard this phrase :)
<bartbes>
swap doesn't sound good for flash based disks though
<viric>
I try to use swap only for waiting processes, not for running
<bartbes>
I mean, isn't RAM supposed to be very volatile?
<viric>
Some day I should learn to adapt that 'swapiness' to my target of "only for waiting processes, not for running"
<bartbes>
won't this mean that if swap is needed it'll write a lot, fast?
<viric>
bartbes: swap can be used to put resident size of *waiting* processes apart.
<viric>
while another process is doing the heavy work.
<viric>
But I don't like if the OS decides to use the swap for the heavy work
<bartbes>
true, but it still implies semi-rapid change
<bartbes>
in any case swap data is supposed to live waaay shorter than your avarage file
<viric>
Well, I can afford if the mingetty or bash on the terminals I don't use go to swap, and then it takes a few seconds to come again
<bartbes>
I have no idea what the data sheet of the nand lists as the max num of write cycles
<bartbes>
but it doesn't help wasting them
<viric>
bartbes: "life of an average file"? I see this as a fantasy measure
<viric>
I still have to learn to use the softvol....
<viric>
kyak: do you use softvol?
<viric>
My previous attempts were failed on that.
<bartbes>
viric: why?
<viric>
why?
<viric>
I mean... "why" about what?
<viric>
why I failed about softvol? Due to lack of competence I imagine :)
<bartbes>
?
<bartbes>
oh
<bartbes>
no, I meant, why did you see that as a fantasy measure
<viric>
ahh
<viric>
Well, for some files I want them to live long.
<viric>
For some not. There are quite different circumstances for every file I use.
<bartbes>
sure, but there's an avarage
<bartbes>
:P
<bartbes>
maybe I should've said "avarage life of a file"
<viric>
I don't accept an average of something with a big standard deviation ;)
<kristianpaul>
juan64bits: i dint understand your last commit
<kristianpaul>
i cant see what changed/added :/
<juan64bits>
the changes are related with the project "SIE Code Generator"
<viric>
yesterday I had to open the thin plastic over the board, that makes the keyboard... the 'down' key worked bad. I cleaned a bit it and it works fine again
<kristianpaul>
juan64bits: ahh my fault i dint realized i can get the diff file
<kristianpaul>
how i see that with git..
<kristianpaul>
viric: you should report that on the list, adding a picture will help
<viric>
uhh
<viric>
I closed all the nanonote again
<kristianpaul>
ah np
<viric>
I don't think that would help much anyone :)