00:00:00 --- log: started forth/21.01.13 00:33:31 --- quit: MrMobius (Read error: Connection reset by peer) 01:06:11 --- quit: iyzsong (Ping timeout: 260 seconds) 01:06:40 --- join: iyzsong- joined #forth 01:07:05 --- nick: iyzsong- -> iyzsong 01:24:41 --- join: dave0 joined #forth 01:26:22 siraben, for Thailand it was just political. The machines were pretty good. 01:27:30 I think the guy behind it Neopolit---something or other just moved on to other things. I think there may have been some political infighting or something. They did have a few good deployments around the world that I think would be considered successful. 01:28:31 Do you think mass mobile adoption replaces the need to have OLPC programmes? 01:45:59 https://www.excamera.com/sphinx/fpga-j1.html 02:44:44 --- quit: proteus-guy (Ping timeout: 260 seconds) 04:02:14 --- quit: cantstanya (Remote host closed the connection) 04:09:59 --- join: cantstanya joined #forth 04:30:10 --- quit: iyzsong (Quit: ZNC 1.7.5 - https://znc.in) 04:31:13 --- join: iyzsong joined #forth 04:51:00 --- quit: iyzsong (Quit: ZNC 1.7.5 - https://znc.in) 04:51:58 --- join: iyzsong joined #forth 04:54:00 siraben, no because the concept of OLPC was for kids to understand how it worked, be able to write their own code, and interact via a peer-to-peer swarm network. Mobile devices are locked down and you can't see the code. On OLPC there was a gear button that, when pushed, showed you all the python source code for whatever it was you were running. And you could change it and try new things. 04:54:40 dave0, oh yeah the J1 forth cpu is a great little thing! 04:55:28 I've got one of these shipping to me that I'm looking forward to playing with. Has a j1 on it. https://www.excamera.com/sphinx/gameduino/index.html#gameduino 05:58:34 Mass mobile adoption has been great, but let's not kid ourselves, kids who grow up with phones and tablets instead of desktop PCs are missing out 05:58:44 Desktop PCs / laptops 06:02:37 --- quit: dave0 (Quit: dave's not here) 06:05:59 --- quit: Vedran (Ping timeout: 264 seconds) 06:06:42 --- join: Vedran joined #forth 06:26:01 --- join: lispmacs joined #forth 06:26:41 my post on installing FlashForth on Arduino: https://librehacker.com/2021/01/12/first-foray-flashforth-for-avr/ 06:49:30 --- join: MrMobius joined #forth 06:54:32 --- quit: gravicappa (Ping timeout: 256 seconds) 06:55:49 --- join: gravicappa joined #forth 07:12:56 lispmacs: i've argued before that even in compiled code, one SHOULD have to intentionally call a special function to write to eeprom, as compared to flash or regular memory, because you can only do so a limited number of times, and doing it in a hot loop would quickly kill the chip 07:44:54 floatcomplex: well, the eeprom memory is mapped to a different memory region than the ram and flash, and I think new words only compile to flash, so it is a bit hard to imagine myself accidentally writing to EEPROM. 07:46:03 seems like a non-issue to me, but you could come up with a new word that only writes to EEPROM space 07:48:11 like e@, that just takes a memory address and offsets it into the EEPROM memory space 07:49:19 err, e! 08:01:59 maybe he means like a pointer error? 08:02:05 which is easy to do 08:12:03 --- quit: iyzsong (Quit: ZNC 1.7.5 - https://znc.in) 08:13:01 --- join: iyzsong joined #forth 08:22:09 MrMobius: i meant not realizing you were writing to eeprom instead of any other regular variable because it's not obvious from looking at the code 08:22:20 perhaps more of a problem in higher level languages 08:22:29 and when working on other peoples' code 08:41:47 --- quit: dys (Ping timeout: 240 seconds) 08:56:12 floatcomplex, thats what I mean 08:56:34 if you have a pointer to ram and add or subtract the wrong offset, you could accidentally be pointing at eeprom right? 09:12:52 --- join: proteus-guy joined #forth 09:30:26 --- quit: proteus-guy (Ping timeout: 246 seconds) 09:41:09 the safety issues don't concern me personally, but I could see some advantages to separate words from a performance perspective, if once was being really careful with cycles. In AVR Flashforth, there is a 2 cycle overhead on @ and ! calls, due to the memory mapping 09:44:31 hmm, you can do a compare and jump in 2 cycles? 09:45:19 on windows 3.1 any program could access the whole memory so when one of them made a pointer mistake, it would write junk into another program's space 09:46:51 so anyway, things like that show how it's important to have some type of remedy 09:48:53 I think trying to compare Window 3.1 desktop operating system management to memory type management in programming an AVR chip is quite the leap 09:51:19 I don't see how having separate words really solves the problem. If you are using somebody elses code, they can just as easily have hidden the danagerous eeprom access call inside of one of their own words 09:52:37 and a bad offset calculation into eeprom space might be a bummer, for sure, but any bad offset calculation is going to be bad thing in your system 10:02:05 yeah when it comes to eeprom i'm less worried about accidentally writing to eeprom due to like bad offset calculation, and more about the next person who works on the code and doesn't realize it's not like other variables and they shouldn't make that loop faster 10:03:24 a little `e' prefix to the variable name? 10:05:21 would you be writing to eprom at all in a loop? 10:05:24 (i'm specifically bent out of shape about this due to some evil c++ code that overrode the * operator, yes not the = operator but the * operator, in such a way that it could be used to make a simple assignment write to eeprom. no possible good can come from that use of overloading) 10:05:36 lispmacs: not if you knew it was eeprom :) 10:06:48 yeah, but I mean, if I'm going to create an eeprom variable, it is going to be something like "userpassword" which isn't going to be loop updated 10:07:34 if I create something like "lasttempreading", I'm not going to put that to eeprom in the first place 10:07:51 *point that 10:12:44 again though, it would only be like a 2 minute project to implement those extra "safe words" if you wanted them 10:17:46 lispmacs[work], famous last words :) 10:17:55 probably fine though if its just your hobby project 10:18:27 assuming your not putting flashforth in an automoble ECU 10:24:36 something constructive to mention would be the flashforth `inline' directive, so you could just alias ! to e!, if the goal was simply to make it obvious in code that an eeprom write was happening 10:28:44 --- quit: Vedran (Ping timeout: 256 seconds) 10:28:53 --- join: Vedran joined #forth 10:29:14 --- quit: gravicappa (Ping timeout: 246 seconds) 10:29:35 but at the end of the day, it is possible for somebody to use ! for eeprom writes. I was previously using Arduino-FVM, which I think didn't have any words for EEPROM writes 10:29:53 under the hood it's actually doing something different than it would do to access sram or flash though 10:30:17 right? otherwise avr-libc would just expose it in the address space too 10:30:47 for sure, yes. IIRC, in AVR you access the eeprom through writes to a I/O register 10:31:23 --- join: gravicappa joined #forth 10:31:54 the I/O register(s) being accessible through normal ram memory accesses or through a special i/o instruction that is a little faster 10:36:21 --- join: WickedShell joined #forth 11:22:07 --- join: Zarutian_HTC joined #forth 11:34:57 --- join: dys joined #forth 12:12:29 --- quit: Vedran (Ping timeout: 246 seconds) 12:13:29 --- join: Vedran joined #forth 13:06:07 --- quit: gravicappa (Ping timeout: 240 seconds) 14:01:18 --- quit: xek (Remote host closed the connection) 14:01:43 --- join: xek joined #forth 14:05:53 --- quit: xek (Ping timeout: 246 seconds) 14:37:12 --- quit: Zarutian_HTC (Remote host closed the connection) 15:18:41 --- join: Croran joined #forth 15:20:49 --- quit: jn__ (Ping timeout: 272 seconds) 15:23:14 --- join: jn__ joined #forth 16:25:30 --- quit: the_cuckoo (Ping timeout: 256 seconds) 17:06:35 --- quit: proteusguy (Ping timeout: 264 seconds) 17:20:05 --- join: proteusguy joined #forth 17:20:05 --- mode: ChanServ set +v proteusguy 17:47:21 --- join: the_cuckoo joined #forth 17:53:28 --- join: dave0 joined #forth 18:34:43 --- quit: dave0 (Quit: dave's not here) 18:40:12 --- quit: WickedShell (Remote host closed the connection) 18:45:00 --- join: boru` joined #forth 18:45:03 --- quit: boru (Disconnected by services) 18:45:05 --- nick: boru` -> boru 20:03:24 --- quit: Croran (Ping timeout: 264 seconds) 20:04:11 --- quit: sts-q (Ping timeout: 264 seconds) 20:06:12 --- join: sts-q joined #forth 21:04:12 --- quit: sts-q (Ping timeout: 272 seconds) 21:06:46 --- join: sts-q joined #forth 21:07:32 --- quit: Keshl (Read error: Connection reset by peer) 21:08:36 --- join: Keshl joined #forth 21:15:14 --- quit: Keshl (Read error: Connection reset by peer) 21:15:48 --- join: Keshl joined #forth 21:20:28 --- quit: Keshl (Read error: Connection reset by peer) 21:21:11 --- join: Keshl joined #forth 21:24:54 --- join: gravicappa joined #forth 21:28:36 --- quit: Keshl (Read error: Connection reset by peer) 21:29:05 --- join: Keshl joined #forth 21:30:01 --- quit: Keshl (Read error: Connection reset by peer) 21:30:46 --- join: Keshl joined #forth 21:37:34 --- quit: Keshl (Read error: Connection reset by peer) 21:37:49 --- join: Keshl joined #forth 21:55:37 --- join: jedb_ joined #forth 21:58:36 --- quit: jedb (Ping timeout: 260 seconds) 22:28:33 --- join: jedb__ joined #forth 22:30:56 --- quit: jedb_ (Ping timeout: 246 seconds) 22:32:40 --- join: proteus-guy joined #forth 22:39:19 --- nick: jedb__ -> jedb 22:42:48 --- join: xek joined #forth 23:47:41 --- quit: gravicappa (Ping timeout: 260 seconds) 23:59:59 --- log: ended forth/21.01.13