Croran has quit [Quit: No Ping reply in 180 seconds.]
Croran has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
$ badc0ffeefaceb0b
<rdrop-exit>
^ magic filler for 64 bits
<tabemann>
hey guys
<rdrop-exit>
hi tabemann
<tp>
hey tabemann
<tabemann>
I use $DEADBEEF in zeptoforth
<rdrop-exit>
ya, that's the classic one for 32-bits
<rdrop-exit>
another one I use for 64 bits is: $ 1cedc0ffee4babe5
<tabemann>
I made a new release for zeptoforth, where I reorganized the HERE-related words
<rdrop-exit>
cool
<tabemann>
so , is now RAM, CURRENT, is now , and FLASH, is still FLASH,
<tabemann>
likewise HERE is now RAM-HERE, CURRENT-HERE is now HERE, and FLASH-HERE is still FLASH-HERE
* tp
passes out from word overload syndrome
<rdrop-exit>
:-))
<rdrop-exit>
HERE THERE EVERYWHERE
<tp>
so RAM-HERE is here, but tabemann wouldn't hear of using FLASH-HERE, here, if it was THERE ?
<tp>
lol
<rdrop-exit>
ANYWHERE
* tabemann
is mesmerized by the blinky he's got running for like the last 45 minutes
<tabemann>
it's a four-color blinky that goes round in a circular pattern
<rdrop-exit>
you are getting sleepy, very sleepy, when I snap my fingers you will...
<tabemann>
actually I am sleepy
<tp>
your eyelids feel like lead ....
<tabemann>
886frrdurittivtv7o7otogy7
<rdrop-exit>
you will tell me the combination to the safe...
<tp>
soon you will forget ever trying to use functional programming in Forth, when I snap my fingers every time you see C code you will throw up all over it
* tabemann
wakes up
<rdrop-exit>
:))
<tabemann>
isn't "functional forth" what factor is supposed to be?
<rdrop-exit>
there have been a bunch of different "functional forths"
<rdrop-exit>
and a bunch of "onject-oriented forths"
<rdrop-exit>
* object
* tabemann
is guilty of adding object-orientation to hashforth
* tabemann
is also guilty of adding dynamic memory allocation and preemptive multitasking to hashforth
<tabemann>
these things are less tempting with zeptoforth, since zeptoforth has only so much memory
<rdrop-exit>
they always seem bent on injecting cruft and inefficiencies at the lowest levels of the Forth VM
<rdrop-exit>
in the name of some beloved paradigm
<rdrop-exit>
Forth already has "words", the best paradigm of all
<tp>
my word it does!
<rdrop-exit>
:)
<tabemann>
well in my case, the only added cruft as adding support for safe blocks
<tabemann>
and even they weren't part of the VM
<tabemann>
well, the dynamic memory allocation was inefficient
<MrMobius>
or in the name of finishing the project some time in the next 300 years :)
<tabemann>
but this wasn't part of the VM
<rdrop-exit>
... the only way to realistically realize the performance goals
<rdrop-exit>
and the computer at the same time.
<rdrop-exit>
software could not use...
<rdrop-exit>
and make them accessible to the user was to design the compiler
<rdrop-exit>
In this way features would not be put in the hardware which the
<rdrop-exit>
-- Fran Allen, 1981
<tp>
tabemann, dynamic memory ? with a GC ?
<tabemann>
no, not with a GC
<tabemann>
what kind of insanity would drive one to make a Forth with a GC?
<tabemann>
well... there is a GC library for C so it might be possible
<tp>
the same kind of insanity that drove people to use micropython on embedded ?
<tp>
or eLUA
<tp>
or eLISP ?
<tabemann>
well hashforth is meant for PCs, so memory is not on short supply
<tp>
yeah
<tp>
I think all the experimentation people do with Forth is good, one never knows what may prove to be useful
<tabemann>
whereas I wouldn't think of putting memory dynamic memory allocation in zeptoforth
<tabemann>
where the main means of freeing memory is to enter "reboot"
<rdrop-exit>
I guess very high level data munging/text processing applications on desktops or servers, e.g. XML processing and such
<tabemann>
e.g. I did not even provide a means of freeing task
<tabemann>
once a task is created it is there permanently until the next reboot
<tp>
makes sense to me
<rdrop-exit>
my PC Forth VM has two tasks built into the "virtual processor"
<tabemann>
one idiom for using tasks in zeptoforth is to, similarly, have two task, one for the REPL, and to run a scheduler in the other task to invoke any number of lightweight "actions"
<tabemann>
like the blinky I have running right now has two tasks, one for the REPL, and one for a scheduler which runs eight lightweight actions
<tabemann>
the actions each have their own separate timing and turn on and off the four LEDs
<rdrop-exit>
a task scheduler? I thought you were doing cooperative multitasking
<tabemann>
rdrop-exit: I am; what the scheduler is it is like a cooperative multitasker, except it just runs words based upon whether they are enabled and at what times they are scheduled to execute
<tabemann>
the multitasker is similar, but it has separate stacks and dictionary spaces for each task, while the scheduler has no such things beyond those belonging to the scheduler's task itself
dddddd has quit [Ping timeout: 256 seconds]
<tabemann>
okay, I'm gonna hit the sack
<tp>
tabemann, I like your designs, a two task scheduler sounds very practical to me
<tp>
nighto tabemann
<rdrop-exit>
I'm not sure I understand what you mean by "it is like a cooperative multitasker", the "cooperative multitasker" is just the word PAUSE normally
<rdrop-exit>
goodnight tabemann
<tabemann>
rdrop-exit: rather than PAUSE the word just returns
<rdrop-exit>
I'm lost
<tabemann>
because the word returns, there is no need to maintain a stack or an rstack for it
<rdrop-exit>
a stack and an rstack for what?
<tabemann>
for a scheduled action, unlike a task
<tabemann>
most actions take the form of, essentially "execute this word at that time"
<tabemann>
each action just uses the data stack and rstack of the parent scheduler's task
<rdrop-exit>
I guess I'm getting confused by your use of the term "sheduler"
<rdrop-exit>
* "scheduler"
<tabemann>
it really just allows setting delays for words' execution until set times as well as just turning words' execution on and off
<tabemann>
it's not a multitasker because what it schedules are not tasks
<tp>
and takes a lot less ram than a multitasker
<tabemann>
yes
<tabemann>
with a multitasker each task has to have a data stack, and rstack, and a dictionary space, all of which eat up lots of RAM
<rdrop-exit>
tp, the "multitasker" in a cooperative Forth is just simply the word PAUSE
<tabemann>
rdrop-exit: that PAUSE requires having a data stack, an rstack, and a dictionary space for each given task
<tp>
rdrop-exit, in Mecrisp-Stellaris there is a lot more code than the pause word for the multitasker
<rdrop-exit>
tabemann, but that is adjustable, a terminal task gets more, a background task gets less
<tp>
rdrop-exit, it's a bit complex so I dont know much about it
<rdrop-exit>
a coroutine on the other hand has no stacks of its own
<tabemann>
rdrop-exit: yes, that is true, but even if you give them the minimum size they still take far more space than one of my scheduled words
<tp>
so is a scheduler a coroutine ?
<tabemann>
rdrop-exit's coroutines apparently involve swapping the top of the rstack and the top of the data stack
<tabemann>
whereas my scheduler doesn't save any state at all about the scheduled words; they're just words that are called when scheduled
<rdrop-exit>
top of the rstack and instruction pointer
<tp>
tabemann, thats what I was trying to achieve recently
<tp>
hey COBOL experts ...New Jersey needs COBOL programmers because many of the state’s systems use older mainframes, and those systems are now seeing record demand for services as the coronavirus outbreak disrupts the economy.
<tp>
For example, an unprecedented 362,000 people have applied for unemployment in New Jersey as a result of the coronavirus outbreak, and the state’s IT department is working to have the 40-year-old mainframes that power that service up and running,
<tabemann>
rdrop-exit: how do you accomplish having more than two coroutines that way?
<rdrop-exit>
what do you mean?
<tabemann>
also, my scheduler has timing as a key element to it, and it automatically puts the MCU to sleep (if combined with the multitasker) if no actions are ready
<tabemann>
rdrop-exit: how do you maintain state for > 2 coroutines with that?
<tp>
tabemann, nice!
<rdrop-exit>
I understand what you're saying, it's just that what you're calling a "scheduler" is not what is usually called a scheduler, but that's ok, I get what you're saying
<tabemann>
(that's why it's recommended that one always combine the scheduler with the multitasker, as it is the multitasker which actually handles putting the MCU to sleep; the scheduler just tells it that it is waiting)
<rdrop-exit>
the "multitasker" in a cooperative Forth is just the word PAUSE
<tabemann>
the multitasker in zeptoforth manages task waiting, and if all tasks are waiting it puts the MCU to sleep
<rdrop-exit>
"manages task waiting"
<tabemann>
e.g. a task can be disabled, or it can be waiting for an interrupt, or it can be waiting for a certain time
<rdrop-exit>
typically a cooperative Forth task uses PAUSE to hand off the CPU to another task
<tabemann>
well it does do this, unless it cannot find any enabled, non-waiting tasks
<rdrop-exit>
if the Forth task is waiting for an interrupt it STOPs itself, which takes it out of the PAUSE ring
<rdrop-exit>
the interrupt (or some other task) can insert it back into the PAUSE ring
<tabemann>
in zeptoforth it marks itself as waiting, and when the processor wakes up, it tries to do something, and if it still can't do anything, it puts itself back in waiting state
<tabemann>
except if it is waiting for a time
<rdrop-exit>
the ring itself is just a slot in each tasks descriptor that contains the address of the next task in the ring
<tabemann>
where then PAUSE will not execute the task at all until the waited-for time is reached
<rdrop-exit>
there's no need for a waiting state, the STOP removes the task from the ring
<rdrop-exit>
basically not being in the ring means it doesn't get handed the CPU each time around the ring
<rdrop-exit>
there's no need to check it's state
<rdrop-exit>
your "waiting state" is implicit in a cooperative multitasker
<rdrop-exit>
if there are 3 tasks, A B C, each PAUSE jumps to the next task, ABCABC...
<rdrop-exit>
If task B is waiting for an interrupt, it just STOPs itself, which means it removes itself from the ring, which is now ACACAC...
<tabemann>
what you're saying though implies that you need a separate ring, a "waiting" ring, consisting of tasks waiting for interrupts so they can be woken up by them and put back into the main ring
<rdrop-exit>
no time is wasted on B anymore until it gets hooked back into the ring
<rdrop-exit>
no, waiting tasks don't need a ring
<tabemann>
so how will you know to wake them up?
<rdrop-exit>
when you want them to wake up, you insert them back in the ring
<tabemann>
how do you know to do that?
<tabemann>
a task outside the main ring doesn't exist unless you put it somewhere else
<rdrop-exit>
the interrupt handler can do it, or another task
<tabemann>
also, how do you handle tasks waiting for a time?
<tabemann>
it's not like a task waiting for IO
<tabemann>
where it cna just run right away
<tabemann>
you don't want to wake up a task waiting for a time each time a SysTick occurs
<tabemann>
so if you don't have the in the main ring
<tabemann>
you'll need to put them in a second ring
<tabemann>
and execute the timing logic each time a systick occurs
<rdrop-exit>
depends how long, if it's a short delay you use a delay word, if it's a long delay you either have a timer interrupt do it, or a task that is intimate with the timer interrupt
<tabemann>
my systick time is short, 1/10th of a millisecond
<rdrop-exit>
systick is not your only timer possibility
<tabemann>
I know
<rdrop-exit>
if it's a very short time you don't bother with the extra overhead, you just PAUSE and when you regain the CPU check if enough time has passed
<rdrop-exit>
if it's a very long time, then some more specialized timer is probably involved
<rdrop-exit>
if you have a ton of things you need to schedule, then you setup something similar to what you called your "scheduler" task
<tabemann>
the main way that timing is currently done with tasks in zeptoforth is to set a delay then calling PAUSE (or calling MS, which calls PAUSE), which sets a time to delay to, where then the task is ignored until the systick counter reaches that time (with the MCU being slept as appropriate along the way)
<tabemann>
for really slow delays I can see using a busy-loop
<tabemann>
but that has the disadvantage of denying CPU time from other tasks
<rdrop-exit>
you have two choices depending on how long a delay, if it's a short delay you use MS or something similar with a built-in PAUSE, if it's a long delay you remove yourself from the ring by using STOP, and have an interrupt handler or another task insert you back in the ring
<rdrop-exit>
that way for long delays you don't waste CPU cycles
<rdrop-exit>
and for a very short delay you don't waste time on unneeded overhead
<tabemann>
anyways, I should really get to bed
<tabemann>
g'night for real now
<rdrop-exit>
goodnight tabemann, stay healthy
jsoft has joined #forth
merkc2 has joined #forth
<rdrop-exit>
The cheapest, fastest, and most reliable components are those that
<rdrop-exit>
aren't there. -- C. Gordon Bell
Lord_Nightmare has quit [Ping timeout: 256 seconds]
Lord_Nightmare has joined #forth
gravicappa has joined #forth
_whitelogger has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
merkc2 has quit [Quit: Leaving]
jsoft has quit [Ping timeout: 256 seconds]
jsoft has joined #forth
mtsd has joined #forth
xek has joined #forth
nonlinear has quit [Ping timeout: 260 seconds]
nonlinear has joined #forth
WickedShell has quit [Remote host closed the connection]
TCZ has joined #forth
iyzsong has joined #forth
rdrop-exit has joined #forth
merkc0 has joined #forth
<merkc0>
: gen-shc CREATE
<merkc0>
5 0 DO 1 . LOOP
<merkc0>
gen-shc myc
<merkc0>
DOES> @ ;
<merkc0>
^ 0xC0000005L ACCESS_VIOLATION
<merkc0>
why can't I use DO LOOP after CREATE ?
<rdrop-exit>
shouldn't, which Forth?
dddddd has joined #forth
<merkc0>
you're right, it works when I isolate it; I have some other code above that messes things up
<rdrop-exit>
ok :)
<merkc0>
thanks
<rdrop-exit>
no problem
<merkc0>
BYE
<merkc0>
BYE
* merkc0
wrong window
<rdrop-exit>
:)
<merkc0>
an on implementation without FORGET is it possible to redefine a word at the same address ? (without making a new entry in the dictionary )
<merkc0>
given that the new definition is the same size as the old definition
<rdrop-exit>
in theory, but you'd need detailed knowledge of the internals of the Forth, and even then it may not be practical
<rdrop-exit>
on some simple Forths it would not be hard
<merkc0>
I have a word that contains fixed assembly code and some data which I want to update from user input
<merkc0>
I am not sure how to update the data in that asm code, in an elegant way
<rdrop-exit>
that type of patching should be easy
<rdrop-exit>
while you're assembling your word, save the patch address somewhere
<merkc0>
ok I'll give this approach a try
<rdrop-exit>
if you know the address that you want to patch, just make a constant out of it, and store your patching data at that address
<rdrop-exit>
using c! 16! 32! or whatever depending on the width of the data
<rdrop-exit>
(your Forth may have other names for 16! etc, eg. w! )
<merkc0>
got it
<rdrop-exit>
If you're running on an OS, or on a heavily pipelined CPU, self-modifying code may be problematic
<merkc0>
is it not possible to change 1) backup HERE 2) HERE to point to the desired address and do the word compilation 3) revert to the old backup ?
<rdrop-exit>
you could if your dictionary is combined code & data, but backing up HERE seems more trouble then it's worth if you're just patching a few bytes
<merkc0>
2 bytes and 2 unicode strings
<rdrop-exit>
and you need to be careful not to cause an error while you're temporarily messing with HERE, i.e. DP
<rdrop-exit>
I would just have a constant of the patch address
<rdrop-exit>
is this a desktop system?
<rdrop-exit>
(I ask because you mentioned Unicode)
<rdrop-exit>
if it is a desktop system, than self-modifying code is probably not worth messing with
<merkc0>
yes it's desktop
<rdrop-exit>
just have the assembly code get the data it needs from a variable that you can change based on user input
<merkc0>
I'm injecting this assembly into another process , so I have to inject the data as well
<rdrop-exit>
ah, then another system/process is actually going to run the machine code you're generating, then that's less problematic
<merkc0>
yes it's another system that's running that code
<merkc0>
simple dumb asm code that won't call any forth words
<rdrop-exit>
like a virus?
<merkc0>
like a "good virus", it adds functionality to a software
<merkc0>
which is not extensible by other means
<rdrop-exit>
cool
<rdrop-exit>
if the machine code is intended for a target, then you're situation is much simpler to deal with
<rdrop-exit>
overall
<rdrop-exit>
you can lay down machine code to a buffer, rather than making it part of your dictionary
<merkc0>
how to use C, etc, to lay it down to a buffer ?
<merkc0>
w, 16, 32,
<merkc0>
CREATE buffer then I add the stuff w, w, w,
<merkc0>
then how to lay down again, the same stuff (maybe with some data changed) , at the same buffer address
<rdrop-exit>
you can write variant comma words for the target, maybe tb, t16, t32, etc...
<rdrop-exit>
you reset the pointer that's tracking your usage of that buffer
<rdrop-exit>
variable tp \ target pointer
<rdrop-exit>
create target 128 allot
<rdrop-exit>
: tp0 ( -- ) target tp ! ;
<tp>
nono please dont target me!
<merkc0>
lolz
<rdrop-exit>
tp0 resets your target pointer back to the beginning of the target buffer when you want to reuse it
<rdrop-exit>
:))
<rdrop-exit>
then you make a bunch of comma words that lay down whatever you want into that buffer
<rdrop-exit>
dinner is served, gotta go, stay healthy
rdrop-exit has quit [Quit: Lost terminal]
jedb_ has joined #forth
jedb has quit [Ping timeout: 256 seconds]
mtsd_ has joined #forth
mtsd has quit [Ping timeout: 240 seconds]
mtsd_ has quit [Client Quit]
<veltas>
tp: I read some of that "Extraordinary Popular Delusions..." book, was interesting, but I feel like I'm getting someone's personal slant instead of a balanced look at the history
<veltas>
But it got me interested in stuff I'd not heard of before so I guess I can always research it myself if I really care
merkc0 has quit [Quit: Leaving]
TCZ has quit [Quit: Leaving]
merkc0 has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
Zarutian_HTC has quit [Ping timeout: 264 seconds]
TCZ has joined #forth
gravicappa has joined #forth
<merkc0>
BYE
<merkc0>
BYE
* merkc0
wonrg wnd
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
TCZ has quit [Remote host closed the connection]
TCZ has joined #forth
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #forth
jedb_ is now known as jedb
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
Zarutian_HTC has joined #forth
TCZ has quit [Quit: Leaving]
<veltas>
merkc0: it's too late
<veltas>
We already know you use caps
<merkc0>
:)
<merkc0>
BYE
<merkc0>
BYE
<veltas>
ok
<merkc0>
I'm using a keyboard macro, to automatically switch and trigger compilation
<merkc0>
switch window.. and when xchat happens to be the 2nd window, you get to see BYE BYE
<merkc0>
BYE
<merkc0>
BYE
dave0 has quit [Quit: dave's not here]
<dzho>
so, one sees forths written *for* FPGA's but are there Forth high-level synthesis (HLS) compilers?
<veltas>
So they want to add specific bit width integers to C....... I feel like they are missing that this feature is already in C. Just not how they want it apparantly.
<veltas>
Does their proposal solve a problem other than making it nicer for LLVM?
merkc1 has joined #forth
merkc0 has quit [Ping timeout: 264 seconds]
cox has joined #forth
cox is now known as mark4
<mark4>
anyone here have word that can reverse the order of N1 items on the stack? :)
<mark4>
( x0 x1 x2 n1 --- x2 x1 x0 ) for any value of n1 :)
<mark4>
call it >< the 2 >< would be a swap :P
<mark4>
: swap ( n1 n2 --- n2 n1 ) 2 >< ;
<mark4>
and a swap rot could be done with 3 ><
merkc1 has quit [Ping timeout: 256 seconds]
gravicappa has quit [Ping timeout: 258 seconds]
<tp>
SpaceX is targeting Wednesday, April 22 at 3:30 p.m. EDT, or 19:30 p.m. UTC, for its seventh launch of Starlink satellites
Croran has quit [Ping timeout: 246 seconds]
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 260 seconds]
[1]MrMobius is now known as MrMobius
WickedShell has joined #forth
Croran has joined #forth
jsoft has quit [Ping timeout: 256 seconds]
xek has quit [Ping timeout: 250 seconds]
TCZ has joined #forth
<veltas>
mark4: : >< 1 ?DO I ROLL LOOP ;
<veltas>
If you want to support n1 < 1 then you want an IF as well
<mark4>
im not sure that i roll would do it
<mark4>
i think it would be like doing rot rot rot
<mark4>
where really in this case you would need swap rote
<mark4>
oh wait. maybe it would work :)
<mark4>
i dont think i ever implemented roll :)
<mark4>
pick yes but im not sure roll
<mark4>
it was just an academic question anyway :)
<mark4>
also, not sure we met before :)
<mark4>
hi :)
<TCZ>
"THEN THEN THEN THEN DROP" should be song lyrics
<crc>
mark4: not standard, but:
<crc>
:>< (...n-...) &Heap [ here [ dup , &, times ] dip [ ] a:for-each ] v:preserve ;
<veltas>
A PIC32 sounds fun to be honest, more powerful than what I'm working with atm
<veltas>
mark4: Why write a forth though?
<mark4>
i have written manu, x86 arm, thumb2, 8051, avr :)
<mark4>
pic32 is ok, the damned microchip development tools are utter garbage
<mark4>
speciallhy their IDC4
<mark4>
im writing data out i2c to an external nvm then reading it back in and comparing it to what was written, the test is passing but if i view the contents of the buffers using the freeking IDE they LOOK wrong
<mark4>
utterly fscking useless
<mark4>
wish they had picked armv7 tho
<veltas>
Are they making a lot of these?
<veltas>
PIC32 is cheaper I'm assuming
<mark4>
pretty much everything microchip is garbage imho :)
<mark4>
with pic16 and pic24 you cannot even guarantee the debugger will stop on your breakpoint
<mark4>
you have to use skid buckets, place 2 nops after the opcode you want to stop on
<mark4>
so the cpu can come to a screeching halt
<veltas>
tp: Does 'microchip' mean something other than what I think it does?
<mark4>
eventually
<mark4>
microchip is the maker of the PIC processors
<mark4>
they also own AVR now
<mark4>
unfortunately.
<mark4>
avr is awesome, PIC is garbage
<veltas>
Oh right
<veltas>
'microchip' is kind of what people used to call what is probably called a 'chip' now
<veltas>
that's confusing
<mark4>
thats why they picked that name, they make microchips
<mark4>
brb, letting dog out a ssec
<veltas>
That would be like Ford calling itself Car
<veltas>
Or like me calling myself Glorified Coffee-In-Code-Out Machine
TCZ has quit [Quit: Leaving]
<mark4>
PIC32 however was not designed by microchip, internally its MIPS
<veltas>
Is that why you're writing a forth? Their dev tools suck?
<mark4>
no, im doing it just for the fun of it
<mark4>
we wont be using forth at work :)
<mark4>
im writing the mips assembler first, it will support mips 1, 2, 3 and 4
<veltas>
One day I'm sure I'll find an excuse to use forth at work
<mark4>
where do you work?
<veltas>
If I get proficient enough I might use forth for 'simple scripts'
<veltas>
Not a good idea to put personal info like that under my name
<mark4>
well if you are doing scripts then you are working in linux yes?
<veltas>
We use Windows, Linux I will run a VM for
<mark4>
aha
<veltas>
Not my choice
<mark4>
what forth do you use in the vm or dont you have one there hyet
<mark4>
yet
<veltas>
gforth probably
<mark4>
ick
<veltas>
It's not something I do right now
<mark4>
not a fan of forths written in c
<veltas>
I write my quick scripts in Lua atm
<mark4>
as far as im concerned any forth that can not compile its own sources is deficient
<mark4>
and in the case of a c based forth, is not even forth
<mark4>
not a fan of lua either but its better than python :)
<mark4>
wow's interface was coded in LUA by the guy that wrote SDL
<mark4>
portability is a) a myth and b) pointless, it makes all portable code look like a cluster )$Y(! unmade bed
<mark4>
give me a good design and a good implementation and porting is ***TRIVIAL***
* veltas
shrugs
<mark4>
taking care of all that visual clutter red tape is a horrendous mess
<veltas>
I write 'portable' code for hosted and freestanding environments a lot, athough there is obviously a limit to the portability, with not too much clusteryness
<veltas>
I think it all depends honestly
<mark4>
it can be done, usually when people try to do it they end up making things way worse
<mark4>
java is theoretically portable
<mark4>
c is not
<mark4>
which is why all those libraries need to have #ifdef xxx yyy or zzz all over the place
<mark4>
wikipedia, the oracle of all kowledge.... true and false :)
<mark4>
lol
<veltas>
I don't know about this 'pure' portability but my idea of portability is what CP/M used
<veltas>
I was just using wikipedia for context, not to try to 'prove' anything
<mark4>
i know
<mark4>
and if you touched cpm you are an old fart like me
<mark4>
i never liked z80 tho :)
<veltas>
I've never used CP/M, I just know about software history
<mark4>
aha
<veltas>
What is your quick scripting language?
<veltas>
Like if I asked you to do some simple mundane processing on a load of files, without using a shell script
<mark4>
well i dont do bash, lua or python lol
<veltas>
Because for simple mundane processing on a load of files I know I'd use find or bash, but I mean the general purpose language you choose to do quick and dirty stuff