<stikonas>but instead of building icedtea 1, I compiled slightly patched ecj 4.2 <stikonas>and then I was able to build icedtea 2 with jamvm as VM <stikonas>which in turn builds icedtea 3 with hotspot <stikonas>icedtea 2 with hotspot was failing for some reason in some test although in principle it was functional <fossy>oriansj: there is a small issue with mescc-tools-seed regarding seeds <fossy>in my attempts to build (your) mescc-tools-seed (not mine) from initramfs, i noted that you have to cd into your appropriate architecture before running kaem <fossy>this means that you have to be able to cd which AFAICT requires a shell <fossy>unless there's a way to cd using kaem? <oriansj>fossy: not yet but it would be pretty simple to add to kaem <fossy>hm how would you go about that <oriansj>change the current working directory <oriansj>(I'm really starting to hate GCC's <optimized out> when debugging) <dddddd>fossy, thanks(!!) for the amazing new mescc-tools-seed's readme file <oriansj>It should never get into a loop right? <fossy>oriansj: what does struct cell look like <fossy>oriansj: also sorry for so many pull requests lol, my testing for this was bad especially on edge cases <oriansj>fossy: I'm drawing that now (no worries about lots of pull requests, it is fine) <oriansj>(I am currently drawing what pieces are used on each time right now for the source code) <oriansj>basically MARKED is the bottom bit of the type and the type NUMBER never involves the bottom 2 bits <fossy>oriansj: I don't see why that would loop <oriansj>but yet it is and I have no idea why <oriansj>and provided I included all of the roots, it should also unmark all cells in use <oriansj>for example if I call unmark on a cell down the tree; it will unmark all of the lower bits and when I call unmark higher in the tree; it should stop when it hits the first unmarked cell <oriansj>minor typeo on the vector | VECTOR | LENGTH | POINTER | NULL | is the correct internals <oriansj>but I am going to stop and pick this up tomorrow <oriansj>so how the fuck does unmark(top_env); unmark g_env but NOT g_env->car? <oriansj>So please, someone anyone tell this great big moron how this keeps happening? <janneke>could it be that the computer does as you says, not what you mean? <oriansj>the bottom 2 bits are reserved with the bottom 1 bit for marking <oriansj>So type & MARKED will return 1 if MARKED and 0 if not marked <oriansj>it definitely isn't a LAMBDA so shouldn't do anything in there <oriansj>i->type == CONS definitely is true and it should unmark_cells(i->car); <oriansj>which are the cells that it is explicitly not unmarking <oriansj>and when I gdb into garbage_collect; p* g_env shows mark_all_cells() marks g_env <oriansj>but unmark_cells(top_env); unmarks g_env but nothing below it ***ng0_ is now known as ng0
*janneke is reading the code *oriansj really hates having to troubleshoot garbage collection <oriansj>ok, I'm just going to pull out all optimizations out and see if that saves me from pain <oriansj>ok that gets me closer (but alot slower) <NieDzejkob>debugging garbage collection is easy, just get it right the first time ;) <oriansj>NieDzejkob: well feel free to throw some useful code in here ^_- <oriansj>well I try to shake the bugs out of mes-m2 ***ng0_ is now known as ng0
<oriansj>feel free to tell me all of the wonderful ways in which I am doing things wrong <oriansj>it'll really cut down on my development time (nothing is faster than not having to do the work because better people have done it for you) <oriansj>I keep wishing I wrote better tests on all of the primitives but it turns out most of the primitives needed for testing are deeply connected. <oriansj>basically everything inside of the eval need to be perfect together or endless bugs forever with no way to properly test them <oriansj>for some reason it thinks setting the last field in the record is amazing and will only do that <oriansj>I think that perhaps is so different between compilers and interpreters <oriansj>Once you get past parsing and tokenization in C, the rest is straight down hill <oriansj>but interpreters seems to be an ever increasing ramp, which get harder the more serious programs you wish to run <oriansj>ok I have reduced it a much smaller test <oriansj>well atleast I don't have to get ((lambda (a b) (define a b)) 'foo 4) working <oriansj>ok, I've managed to shift the bug from structs to vargs <oriansj>I turned off alot of optimizations to get here, so it is a bit slow right now <oriansj>I look forward to the day mes-m2's eval guts are *DONE* and I need only concern myself with adding to the non-maxwell parts of scheme <oriansj>now to once again try to get -e main -s foo 1 2 3 4 working in boot-0.scm <oriansj>oh janneke I think I have a little bit of scheme you are going to love <oriansj>(while #t (begin (free_mem) (display #\newline)))