00:00:00 --- log: started forth/08.07.31 00:26:51 --- quit: uiu__ (clarke.freenode.net irc.freenode.net) 00:26:51 --- quit: zedas (clarke.freenode.net irc.freenode.net) 00:27:45 --- join: kar8nga (n=ctc@j-250.vc-graz.ac.at) joined #forth 00:28:53 --- join: zedas (n=zedas@67-207-134-146.slicehost.net) joined #forth 00:28:53 --- join: uiu__ (n=ian@schihei.net) joined #forth 01:05:32 --- quit: JasonWoof (Read error: 110 (Connection timed out)) 01:18:40 --- quit: vixey () 01:20:59 --- join: qFox (i=C00K13S@234pc222.sshunet.nl) joined #forth 01:22:11 --- join: vixey (n=nono@amcant.demon.co.uk) joined #forth 01:59:12 --- join: aum (n=aum@60-234-243-247.bitstream.orcon.net.nz) joined #forth 03:50:46 --- join: GoNoGo (n=GoNoGo@195.83.179.114) joined #forth 04:08:12 --- quit: aspect (Connection reset by peer) 04:08:16 --- join: aspect (i=aspect@burns.dreamhost.com) joined #forth 04:24:44 --- part: kar8nga left #forth 04:24:58 --- join: kar8nga (n=ctc@j-250.vc-graz.ac.at) joined #forth 04:25:08 --- part: kar8nga left #forth 04:42:07 --- quit: aum ("Leaving") 04:44:27 --- quit: vixey () 07:52:28 --- nick: TreyB_ -> TreyB 08:52:35 --- join: insomninja (n=na@c-0e4ee255.54-25-64736c10.cust.bredbandsbolaget.se) joined #forth 09:08:56 --- quit: insomninja ("Lämnar") 09:49:52 --- join: JasonWoof (n=jason@c-65-96-161-30.hsd1.ma.comcast.net) joined #forth 09:49:52 --- mode: ChanServ set +o JasonWoof 10:18:24 --- join: tgunr (n=davec@70-41-252-164.cust.wildblue.net) joined #forth 10:39:16 --- join: Maki_ (n=Maki@adsl-224-84.eunet.yu) joined #forth 11:05:01 --- quit: maht (Remote closed the connection) 11:06:24 --- join: maht (n=maht__@85.189.31.174.proweb.managedbroadband.co.uk) joined #forth 11:58:09 --- join: JasonWoo1 (n=jason@c-65-96-161-30.hsd1.ma.comcast.net) joined #forth 12:12:17 --- quit: JasonWoof (Read error: 110 (Connection timed out)) 12:13:34 --- quit: Deformative (Read error: 110 (Connection timed out)) 13:10:31 --- join: ygrek (i=user@gateway/tor/x-17b7519ce53c05dd) joined #forth 13:16:01 --- join: Deformative (n=joe@c-68-62-76-160.hsd1.mi.comcast.net) joined #forth 13:24:51 --- quit: Deformative (Read error: 104 (Connection reset by peer)) 13:26:15 --- join: Deformative (n=joe@c-68-62-76-160.hsd1.mi.comcast.net) joined #forth 13:38:21 --- quit: Deformative (Read error: 104 (Connection reset by peer)) 13:38:30 --- join: Deformative (n=joe@c-68-62-76-160.hsd1.mi.comcast.net) joined #forth 13:48:19 --- quit: ramkrsna (Read error: 113 (No route to host)) 14:07:03 --- quit: ygrek (Remote closed the connection) 14:32:02 --- quit: Maki_ ("Leaving") 14:38:29 --- join: forther (n=forther@207.47.34.100.static.nextweb.net) joined #forth 14:39:07 --- quit: Quartus (Client Quit) 14:39:19 --- quit: forther (Client Quit) 14:39:24 --- join: forther (n=forther@207.47.34.100.static.nextweb.net) joined #forth 14:40:16 --- join: adasda (n=mathiasc@172.pool85-54-177.dynamic.orange.es) joined #forth 14:40:37 --- nick: adasda -> BobFunk 14:40:44 --- quit: forther (Client Quit) 14:40:52 --- join: forther (n=forther@207.47.34.100.static.nextweb.net) joined #forth 15:15:22 --- join: aum (n=aum@60-234-243-247.bitstream.orcon.net.nz) joined #forth 15:15:52 hi slava, are you around? 15:21:48 --- quit: ASau` (Read error: 110 (Connection timed out)) 16:06:58 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 16:06:58 --- mode: ChanServ set +o tathi 16:13:13 --- join: edrx (i=edrx@189.25.136.233) joined #forth 16:42:44 --- quit: forther ("Leaving") 16:47:46 hi aum 16:47:49 what's up? 16:49:16 aum: i'm gong to cook some dinner but i'll be around in about an hour 16:53:48 --- part: edrx left #forth 17:15:31 --- join: vixey (n=nono@amcant.demon.co.uk) joined #forth 18:01:39 back 18:44:06 aum: you should just state your question and then check the logs later. :) 19:08:31 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 19:19:34 hi slava 19:21:18 sup sup 19:21:32 i wanted to talk to you again about segv handlers 19:21:38 i tried 2 approaches: 19:22:02 --- quit: qFox ("Time for cookies!") 19:22:09 1) longjmp from the handler back to a sane VM state - worked on the first segv, but on the second segv, my handler didn't fire and the prog crashed 19:22:42 2) your approach - adjust SP and IP within the handler context then return - but i ended up returning to the offending line of code, and the handler fired again and again 19:22:57 well the latterw ill work, assuming you really do set the IP correctly :-) 19:23:14 do you mean the VM IP, or the CPU's IP? 19:23:53 ah, you're DTC not STC 19:23:57 yes 19:24:27 the segv scenario i'm testing is '0 @', so the segv is getting caused by a line of C within the '@' primitive 19:24:31 then, in the sigv handler, set the CPU IP to a piece of (C) code which changes teh VM IP, and longjmps to the interpreter loop 19:25:21 slava: that's pretty similar to my first approach - the problem is that when I re-set the segv signal handler, subsequent segv's don't fire my handler, they just crash the process 19:26:26 your first approach would longjmp out of the signal handler 19:26:28 that's a no-no 19:26:29 i already have a setjmp() in place before the offending code executes - if the 'if ((err = setjmp(jmpbuf)) != 0)' picks up an error, it resets the vm 19:26:54 the sigsegv handler should change the IP in the ucontext and return 19:26:56 the CPU IP 19:27:00 but with what you said, aren't you effectively longjmp'ing from out of the sig handler context? 19:27:05 no 19:27:25 or are you saying that I should frig the IP so that when the handler returns, the process then ends up running recovery code? 19:27:35 and do the longjmp from within the recovery code 19:27:43 yes 19:28:02 the trick is - how do I frig the return stack and change the IP without getting into assembler, or ABI formats etc? 19:28:09 is there a way to do that from pure C? 19:29:48 you don't have to worry about any of that if the recovery code does a longjmp 19:30:08 just change the ip in the ucontext 19:30:14 how that's cpu *and* os specific, but its only a single structure field 19:30:20 sorry, there's just no truly easy way of doing this 19:30:39 in factor, i have to mess with the return stack in the signal handler also 19:30:53 and i don't use longjmp at all, for various reasons 19:31:08 so the signal handler dicks with the ip and stack directly 19:32:01 that's ok for you - with factor you're already in the world of platform-specific bits of code 19:32:19 i wonder if I should try gnu's libsegv 19:32:51 btw - is factor STC? 19:33:08 the non-optimizing compiler is STC with some inlining of primitives 19:33:19 right 19:33:36 the optimizing compiler doesn't really qualify as *TC 19:34:30 i'm sure gnu ligsegv is great 19:34:33 i didn't use it because of the license 19:34:37 gpl? 19:34:43 if you're happy with gpl'ing your entire vm, then you should use it 19:34:46 since it takes care of everything for you 19:35:36 i'm known for releasing code as gpl, but selling exemptions to commercial users - but libsegv would take away that option 19:35:42 yes 19:35:53 i'm pretty dead-set on keeping all of factor bsd licensed 19:35:58 i wonder if the libsegv authors might be willing to sell exemptions 19:36:24 the mac os x sigv handler code in factor comes from sbcl 19:36:35 they got the ligsiegv authors to agree to put that one file in the public domain 19:36:44 If UCB had released their TCP/IP stack under GPL, then Windows would have been a whole different history 19:37:24 we may have had 90% of desktop PCs running open source 19:38:55 --- quit: JasonWoo1 (Read error: 104 (Connection reset by peer)) 19:46:55 I did see some arguments on some mailing lists that the only appropriate thing to do in a segv handler is dump out some debug info and terminate the process, since if a segv happens it's possible that the memory space is totally FUBAR'ed - eg heap corruption, stack corruption etc 19:49:21 sure 19:49:25 0 @ won't do that but some other stuff can 19:49:35 in factor, i check if the fault address is the guard page for the stack 19:49:39 if it isn't, its a fatal error 19:49:43 otherwise its just a stack underflow 19:50:10 I have another option - to find malloc/realloc/free equivalents which manage a heap within a specific block of memory 19:50:43 and within the dictionary, to use only relative addresses 19:51:07 if your language has @ and ! you're screwed anyway :) 19:51:24 roflmao 19:51:26 so true 19:51:49 but most errors should be reocverable anyway 19:51:55 but if all addresses are relative to the start of image, then i can vet ! and @ without needing signal handling 19:52:20 yeah but that's a lot of overhead 19:53:04 yet another option - remove @ and ! altogether 19:53:17 heh 19:53:32 add a dynamic type system and a gc, and remove @ ! :-) 19:53:32 my oo system makes them pretty well redundant 19:53:37 what about arays? 19:53:52 i'm using libscl, which has hashtables and lists 19:53:54 dont' you need @ and ! in the implementation of the object system? 19:53:57 oh, ok 19:54:02 do you have forth bindings to scl features 19:54:05 can you make lists ,etc in forth? 19:54:05 yes 19:54:37 i also have bindings to bstrlib for advanced string processing 19:54:53 and intend at some stage to do bindings for libpcre 19:55:30 cool 19:55:46 well, you'd still need to mark strings, lists and hashes as such so that you know what is what at runtime 19:55:57 if you wanted to catch all illegal memory operations 19:56:13 the other options is to create classes for all of those 19:56:40 yup 19:56:48 and teh class methods can wrap the lower-level primitives 19:57:00 i'll stick up a code sample in a sec... 19:58:06 http://www.freenet.org.nz/misc/fltk.fc - bindings for the FLTK gui widgets - incomplete but working 19:58:29 how is object memory managed? 19:58:44 refcounts - ugly and simple 19:59:06 doe sthe user have to inc/dec refs manually? 19:59:10 yes 19:59:30 if you scroll down about half way, you'll see class declarations with some methods in forth and other methods in C++ 19:59:31 aum wow cool 19:59:42 I was just looking at that 20:00:40 vixey: i'm cheating badly - that file and other similar files get compiled into a C or C++ source file in which the primitves are declared as functions, and the forth code is packed into a massive string to be EVALUATEd at module load time 20:00:52 aum: well, if instance variables were classified into those that contain integers only, and those that contain pointers, you could do the inc/de automatically when storing into ivars 20:00:56 so aumForth can't just load those files directly 20:02:19 slava: i've got a bit of that already - there are 5 different words for setattr: ->set (write an object) ->set-cell (write a plain int) ->set-float (write a float) ->set-xt (write an XT) 20:02:47 ah 20:03:09 all i'm saying is, if you expliitly declare which ivars contain pointers to other objects, you can do garbage collection 20:03:19 which is more efficient and less error prone than refcounts all over the place 20:03:24 and some sample code which uses it - the GUI shell - http://www.freenet.org.nz/misc/fltk-gui.f 20:03:45 you can still allow low-level stuff with @ ! for efficiency 20:03:56 and have higher-level array, list, hashtable objects with automatic memory management 20:03:58 IMHO, I've ended up with an OO system that allows for readable code 20:03:59 that would be very slick :) 20:04:36 those are some long words 20:04:46 this -> looks pretty verbose 20:04:53 maybe : --> this -> ; :-) 20:05:14 what's the diff between ->set and -> set ? 20:05:27 slava: ':' and ';' are defining words 20:05:46 oh, wait, you have locals| this | 20:05:47 hmm 20:05:51 so you could keep it on the stack 20:05:53 slava: ->set means 'set ivar to an object value', while '-> set' means 'invoke the method called 'set'' 20:06:19 ok 20:07:17 the word '->' is a generic type-sensitive attribute fetcher - if the atribute type is int, double-int or float or object, it just fetches the attribute to the respective stack, but if the attribute type is 'xt', then it pushes 'this' onto the stack then executes the xt 20:08:31 when the gui runs, it redirects I/O to gui widgets 20:08:48 so attributes already have types? 20:09:06 yes - 'cell', 'dcell', 'float', 'object' and 'xt' 20:09:43 cool 20:09:50 so you can already do inc/dec automatically 20:09:55 yes 20:10:16 i guess you still can't do gc since the stack is not typed 20:10:23 yes 20:10:25 if you had a separate object stack you could 20:10:42 i tried that - but the code started to get really messy, and lost its simple elegance 20:10:45 ok 20:11:11 I spent half an hour hitting ctrl-z to revert out all the changes and went back to inc/dec 20:12:31 version control :) 20:12:33 use it :) 20:13:03 i'd like to migrate the whole thing to STC, but I don't know a platform-independent way of generating C function calls 20:13:52 llvm 20:14:04 it can do more advanced optimizations too 20:16:02 llvm? 20:16:45 oh 20:16:47 got it 20:16:56 how big is the runtime? 20:17:12 about 1mb 20:17:18 :( 20:17:24 you generate llvm IR 20:17:28 and llvm compiles it to native code 20:17:43 the IR is a C-like language, but you built it using LLVM's C++ API 20:17:50 its codegen is competitive with gcc 20:17:59 one of the aims of aumForth is to be able to run on mid-range MCUs like ATMega 20:18:17 well, will you be compiling code on the MCU? 20:18:23 if you're fine with cross-compiling, you can use LLVM 20:18:31 you don't need it to run the code that gets generated, only to compile it 20:18:38 ok 20:30:39 --- join: JasonWoof (n=jason@c-65-96-161-30.hsd1.ma.comcast.net) joined #forth 20:30:39 --- mode: ChanServ set +o JasonWoof 20:31:02 anybody recognize this logo? http://jasonwoof.com/downloads/zebra_logo.png 20:31:11 saw it in a montage of free software logos, and I'm drn curious 20:42:28 --- quit: vixey (Read error: 54 (Connection reset by peer)) 20:42:37 --- join: vixey (n=nono@amcant.demon.co.uk) joined #forth 20:46:38 --- quit: tathi ("leaving") 21:02:15 --- quit: JasonWoof (Read error: 110 (Connection timed out)) 22:36:08 --- part: BobFunk left #forth 22:43:57 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 23:26:01 --- join: ASau` (n=user@79.111.25.149) joined #forth 23:50:03 --- join: ygrek (i=user@gateway/tor/x-0da56acec78482e0) joined #forth 23:59:59 --- log: ended forth/08.07.31