00:00:00 --- log: started retro/11.11.23 00:18:27 __tthomas__: you got an python implementation for colorforth ? 00:26:05 <__tthomas__> no, made changes to python version for retroforth to support color like the linux c version does 00:26:55 <__tthomas__> haven't tested it on linux yet, but just uses readline so think it would work.. 00:50:01 support what color? 00:50:19 can you send me a test version ? i am using linux now 03:13:30 --- quit: __tthomas__ (Quit: Leaving.) 03:25:26 --- quit: roardeZz (Quit: Leaving) 04:06:08 jyfl987: the canvas support under android reports the last touched position (via the mouse queries), but I haven't found a reliable way to determine if the screen is actively being pressed 05:20:28 image: change build identifier to static date : http://rx-core.org/rx.fossil/info/668b01985c4da6d9b47f0d24ce20b1d188a9f93f 05:22:23 image: alter kernel to support possible building with just the kernel : http://rx-core.org/rx.fossil/info/169b01666e6e9a11eb5711746cd62f54e6856817 05:33:50 core: add alternate metacompiler that only uses initial kernel for rebuild : http://rx-core.org/rx.fossil/info/fe51552211797ec57d81352c8d048852ed2fa09c 05:35:27 crc: i think you can process it like an cpu does 05:35:44 crc: for example define a callback 05:36:53 crc: : mycallback do_stuff ; ' mycallback TOUCH_SCREEN_CALLBACK ! 05:46:49 but how to detect the actual touch event via javascript? 05:48:26 this is somewhat problematic since retro's vm isn't realtime; quick touches can be missed easily 05:48:51 callbacks would require non-standard additions to the vm 06:03:58 so you need to launch an retro version implement by android's dalvik vm not by js 06:05:10 which is substantially more difficult (in terms of time) than the current approach 06:06:11 yes 06:06:43 ok lets change the mind 06:07:25 we can make an java framework which handle any events to an embed retro vm for processing it 06:07:49 so it wont require to change retro's vm design and can make real apps for android 06:10:08 there's an implementation of the vm in java, which helps. but I've not had time to learn the UI parts of Android 06:11:27 I also have the issue that my computers won't run eclipse or the simulators at any reasonible speed, so I do all work from the command line 06:13:16 i am not like eclipse too 06:13:28 but i dont know java programming 06:14:24 have tried lua python, neigher of them is powerfull 06:18:22 I like python myself 06:19:29 i am a python engineer 06:19:56 i not meaning python sucks , just the ase implementation for python and lua sucks 06:20:36 they use a java rpc server backend to provide gui operation ,and both lua and python is just a rpc client 06:21:45 ahh, ok 06:22:35 I may have time to work on a native android implementation after new years 06:22:58 but as you have said you dont like to change the design of retro 06:23:54 --- quit: jyfl987 (Quit: Leaving.) 06:36:44 --- join: luptenschteiner (~User@unaffiliated/probonono) joined #retro 06:38:30 --- quit: probonono (Ping timeout: 244 seconds) 07:16:08 for roarde: http://rx-core.org/dev/corpse/article/160 07:40:09 --- join: __toddb__ (~Owner@ubr01-g0-1.westchester.ca.la.comcast.net) joined #retro 07:57:40 --- join: Kumul (~Kumul@66-50-191-73.prtc.net) joined #retro 08:23:27 --- quit: luptenschteiner (Read error: Connection reset by peer) 08:24:28 --- join: luptenschteiner (~User@unaffiliated/probonono) joined #retro 08:32:16 --- join: __tthomas__ (~tthomas@ubr01-g0-1.westchester.ca.la.comcast.net) joined #retro 08:33:04 --- part: __toddb__ left #retro 09:50:40 --- join: __tthomas__1 (~tthomas@slosvr6.aeromecheng.com) joined #retro 09:53:47 --- quit: __tthomas__ (Ping timeout: 276 seconds) 09:54:03 docs: start of a "cheat sheet" for syntax and basic functionality : http://rx-core.org/rx.fossil/info/e6e2782ec13676f15acd47a73c83bc0c66cd8ceb 10:48:06 docs: cheat sheet: add loops, vocabularies : http://rx-core.org/rx.fossil/info/89de801ff58b13a81d7452eef915bdf7397b76f9 10:58:58 --- quit: TheStitch (Ping timeout: 240 seconds) 11:01:40 --- join: TheStitch (~Stitch@awesomefield.stoned-it.com) joined #retro 12:16:33 --- join: Mat2 (2e730ab3@gateway/web/freenode/ip.46.115.10.179) joined #retro 12:17:05 hi @ all 12:18:09 <__tthomas__1> hi 12:19:07 hello 12:20:58 I have finished my vm, only working on optimisation issues with in-order architectures (like Atom) now 12:21:35 after 2 jears of development :) 12:24:56 <__tthomas__1> thats awesome 12:25:09 <__tthomas__1> what type of vm? 12:25:46 a replacement for ngaro 12:26:21 <__tthomas__1> cool, for what platform? 12:28:51 cpu architectures: x86-32, x85-64, iAtom, ARM7, SH4 and PowerPC (AOT compiler backends) 12:29:11 posix compatible operating systems 12:30:29 <__tthomas__1> c version? 12:31:25 yes. The Compiler is an optional feature, the vm supporting generation of new instructions as stream of opcode traces into either machine-code or DTC 12:31:41 image: small cleanup to isNumber? : http://rx-core.org/rx.fossil/info/97f92ee2ab12d72874d7e3ebc9ff308116c6819a 12:32:01 <__tthomas__1> ah, so its a JIT compiler? 12:32:34 some sort of, yes 12:33:16 <__tthomas__1> cool, I am targeting embedded processors so trying to get vm down as small as possible.. 12:36:23 I'm searching for max. performance for both interpreter and compiler without any compromise 12:37:18 the interpreter bundles up to 16 instructions into an opcode (64 bit word size) 12:38:05 so the code depth is very high 12:39:22 and immediate parameters can be shared between code blocks (because there are adressed as separate segments in memory) 12:40:28 the code size of the vm itself isn't small however (64-128 kB for x86-64) 12:41:24 --- join: __tthomas__ (~tthomas@slosvr6.aeromecheng.com) joined #retro 12:44:56 --- quit: __tthomas__1 (Ping timeout: 240 seconds) 12:47:12 <__tthomas__> yeah, I figured as such, probably uses a bit of ram for generating those opcodes as well.. I am looking for a way to optimize image to seperate dictionary out of rest of image file to make it rommable.. 12:47:56 <__tthomas__> I figure dictionary mostly just needs to be readable with occasional writes, the code itself would still run pretty fast since doesn't require dictionary lookups.. 12:52:37 segmentation seems a fine way to accomplish this, this can be done on ngaro level and some minor changes in the retro code 12:53:49 <__tthomas__> hmm.. I was going to try and write a program that could move the dictionary and code around manually.. 12:55:56 so you prefer some sort of dynamic remapping, or have I understand something wrong ? 12:56:55 <__tthomas__> I want the dictionary in one file and everything else in another, the dictionary would contain string and xt to where the code is in the second file.. then I could map the code to memory and keep the dictionary in flash.. 12:59:04 ok. 13:01:58 <__tthomas__> if I could would love to organize image as so.. dictionary in external eeprom, code in internal flash, variables in ram... I think in the end just going to get a couple of external 32K ram chips and not worry about it.. 13:03:18 though I must rewrite retro from scratch separating the dictionary this way should not the problem, only time 13:04:04 <__tthomas__> yeah, if I understood the meta compiler better could just rewrite it to generate image way I want it.. 13:06:49 ask crc, i'm sure he will give you some support 13:08:22 <__tthomas__> I am sure, he is a coding machine.. :) 13:08:57 <__tthomas__> His commentary.txt helped a lot, every time I go through it I understand it a little better.. 13:14:51 I found the meta compiler as a nice example of it's class 13:15:27 just a bit cryptic for someone like my with functional programming preferences 13:24:50 so I think not to recreate it 13:26:28 need some sleep, ciao 13:26:36 --- quit: Mat2 (Quit: Page closed) 13:45:14 --- quit: __tthomas__ (Ping timeout: 244 seconds) 13:46:23 --- join: __tthomas__ (~tthomas@slosvr6.aeromecheng.com) joined #retro 13:55:30 --- quit: __tthomas__ (Ping timeout: 260 seconds) 14:06:50 --- join: __tthomas__ (~tthomas@ubr01-g0-1.westchester.ca.la.comcast.net) joined #retro 14:35:26 --- join: jacereda (~Adium@72.pool85-61-197.dynamic.orange.es) joined #retro 14:35:51 hi 14:38:33 I have a new VM implementation that is much faster than the default C VM, how should I contribute it? 15:08:06 --- quit: jacereda (Quit: Leaving.) 16:19:27 --- part: __tthomas__ left #retro 18:29:42 email it to me. crc@rx-core.org 18:29:56 or pastebin and post the url 18:32:19 --- join: jyfl987 (~jyf@unaffiliated/yunfan) joined #retro 18:53:28 --- nick: luptenschteiner -> probonono 19:22:36 --- quit: Kumul (Quit: gone) 23:59:59 --- log: ended retro/11.11.23