00:35:41 <{^Raven^}> >+>++++++++++<[<[-].+.+.>>.<+] prints hex of numbers 1 to 255
00:42:27 <{^Raven^}> OS abstraction layer for esoteric languages
01:05:23 <arke> when is the next BF contest, if any? :)
01:05:36 <lament> you mean the sourceforge thing?
01:06:34 <arke> lament: do you mean me or raven?
01:07:53 * arke slaps lament ;)
01:08:15 <arke> lament: please say a name, ARKE or RAVEN
01:08:47 <{^Raven^}> ...well this is an esoteric chat room after all...
01:09:22 <lament> Doth thou mean the noble Sourceforge site?
01:10:49 <arke> lament: I am not sure of which you speak.
01:11:05 <arke> lament: I saw 2 BF contests on cristofs site
01:11:14 <arke> so i figured there'll probably be more
01:27:36 <calamari> lament: you're right.. I only get the bf urge every once in a while.. but when I do, usually something fun comes of it
01:28:27 <calamari> and I squeezed every last byte out of that boot sector :)
01:43:41 <{^Raven^}> >.++.--.<.+.-.>[-]>++++++++[<+++++++++++++>-]<.<.++.-.+[->.<].[-]++++++++++.
01:43:56 <{^Raven^}> display 'h' if the -h switch has been passed on the command line :D
01:55:43 <cpressey> http://catseye.webhop.net/projects/pesoix/doc/pesoix.html
02:19:28 <{^Raven^}> I've knocked up a page for you to link to
02:22:37 <calamari> how will the overlapping specs be sorted out?
02:25:32 <{^Raven^}> under Easel there are currently 65280 possible unique API calls
02:27:07 <cpressey> well, EsoAPI has the first few 'non banked' commands. Easel has (so far) banks 01, 02, and 03 (which conflict with EsoAPI). and i threw in bank 10
02:28:19 <cpressey> there could in theory be an unlimited number of api calls, if one of the banks admits sub-banks (and one of those sub-banks admits sub-sub-banks, etc)
02:29:23 <{^Raven^}> in theory it is possibe, but whatever the final depth is, I would like all API sections to be as deep.
02:30:23 <{^Raven^}> I could allocate EsoAPI a sub-block of calls but I don't know that I can add low level disk access and keep portability
02:30:45 <cpressey> well, i'd like all the 'common' api sections to be only 1 bank deep, and have anything deeper reserved for 'vendor extensions' :)
02:31:35 <cpressey> the low-level disk access doesn't have to be real... it could be emulated. or more simply, those commands could just be reserved for EsoAPI
02:32:06 <cpressey> since the low-level stuff is mostly useful for booting anyway.
02:32:25 <{^Raven^}> yes, ideally I would like to have them as one specification
02:33:23 <cpressey> i worry that calamari's boot block doesn't have enough space left in it to parse a bank number :)
02:33:57 <{^Raven^}> lets say that I if I use banks 1-9, banks 10-19 could be reserved for the main development team and banks 20-255 would be allocated on a block-by-block basis to different vendors
02:35:09 <{^Raven^}> or even make the vendor blocks another level deep, so each vendor had 65536 calls available
02:38:17 <{^Raven^}> hmmm, this could work... If the user is boots into BFOS they have calamari's current EsoAPI calls available. If they then issue API call 00h 09h it switches to the easel API (now part of EsoAPI)
02:39:26 <{^Raven^}> and from Easel (which they are now in) they issue 00h 09h 01h and that switches them back to the low-level EsoAPI
02:40:04 <{^Raven^}> but, if a user is running a PESOIX enabled interpreter then they only have the Easel functionality available and all low-level EsoAPI calls are emulated
02:41:10 <cpressey> hmmm, a modal api :) actually, that probably makes the most sense. and it's even ugly enough to be kind of esoteric!
02:41:22 <cpressey> i'll think about it for a bit.
02:41:46 <{^Raven^}> calamari, your comments would be appreciated
02:42:17 -!- calamari has quit (Read error: 110 (Connection timed out)).
02:42:37 <{^Raven^}> And it would mean that there is only one PESOIX standard - EsoAPI - if calamari lets me use the name
03:02:49 <cpressey> ok, i like the idea of different 'dialects' (with the default dialect being the BOS aka EsoAPI dialect), and a command to switch between dialects. but the command to switch between dialects should probably be the same in every dialect, or chaos will ensue
03:02:58 <cpressey> (not that that's _necessarily_ bad, mind you :)
03:03:28 <cpressey> and if a particular implementation doesn't support a particular dialect, well, that's ok. but it needs to notify the program of that.
03:04:18 <{^Raven^}> that would allow an infinite number of different PESOIX layers
03:05:03 <cpressey> essentially, yeah. the important thing is that it allows for more overlap.
03:06:09 <{^Raven^}> so...all PESOIX conpliant tools start up in calamari's layer,
03:07:07 <{^Raven^}> and then issue a dialect switching command to switch specifications.
03:09:12 <cpressey> "*** Winner of the 2204 2k Classic Text Adventure Competition ***" - heh, are you a time traveller? :)
03:10:58 <{^Raven^}> load the source code into a BBC BASIC to see a high level language doing a good impression of an esoteric one :)
03:15:19 <{^Raven^}> i arbitarily nominate 00h 09h xxh where xx is the dialect ID, seems logical as 09h is the next free EsoAPI call
03:17:07 <{^Raven^}> 00h 09h 00h would select to the low-level API.
03:19:03 <{^Raven^}> Hopefully...00h 09h 01h would select Easel, with Easel functionality (hopefully) being a requirement for all PESOIX compliant tools. This is to allow all PESOIX tools to have the same basic functionality.
03:25:26 <{^Raven^}> i have added some more info to the site
03:29:53 <cpressey> i'll work on it a bit more too...
03:30:24 <{^Raven^}> this looks like the start of something interesting
05:47:33 <{^Raven^}> The PESOIX site is looking great and is full of good ideas
05:54:49 -!- heatsink has quit ("Leaving").
06:57:01 -!- calamari has joined.
07:43:47 -!- calamari has quit ("Leaving").
07:45:49 -!- calamari has joined.
07:47:31 <{^Raven^}> have completed a working PESOIX source as per the cpressey's specs
07:54:41 <cpressey> i've implemented something too
07:54:52 <cpressey> http://catseye.webhop.net/projects/esobrace/src/esobrace.c
07:55:34 <cpressey> all it does is recognize the SWITCH DIALECT command and acknowledge it, right now
07:56:23 <cpressey> the issues with buffered i/o are a little more painful than i even expected (and i expected quite a bit of pain)
07:56:33 <cpressey> but i think i can work them into the spec
07:56:44 <cpressey> but it's almost midnight here, so that'll wait :)
07:56:46 <{^Raven^}> yeah, every system has it's own way of doing it
07:57:09 <calamari> {^Raven^}: didn't realize you wrote a etxt adventure in bf.. very cool :)
07:57:58 <calamari> I also noticed an @ at the end of the file.. I suspect I corrupted you on that. oops!
07:58:25 <{^Raven^}> there are too many ways that an EOF can happen
07:59:52 <calamari> I used the @ to make my interpreter easier to write.. laziness on my part
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:02:08 <{^Raven^}> cpressey: that's a scary bit of code
08:03:34 <{^Raven^}> here is my pre-alpha http://jonripley.com/easel/pesoix.zip
08:04:15 <{^Raven^}> it supports EsoAPI at start and will allow bank switching when I add the call,
08:04:50 <{^Raven^}> pre-alpha EsoAPI, dialect7f and easal are coded for
08:05:43 <{^Raven^}> it even passes calamari's EsoAPI wrapper test :)
08:08:40 <{^Raven^}> we won't need an '@' at the end of the file soon...we will be able to call the appropriate PESOIX function to check EOF :)
08:09:47 <calamari> do you have an easel test program I can run on my esoapi interpreter (it should abort, correct?)
08:11:17 <{^Raven^}> there are some easel test programs in the above archive
08:12:48 <calamari> what I mean is.. if I try to run an esoapi program on a regular bf interpreter, it will abort (because of the wrapper). What happens if I run an easel program on esoapi.. will it complain, or proceed and possibly crash?
08:15:07 <{^Raven^}> EsoAPI will need to be modified to support dialect switching (aka 00h 09h xxh)
08:16:58 <calamari> I can't support that.. no bytes left
08:17:43 <calamari> all that is needed is some sort of installation check like I did for esoapi
08:18:07 <calamari> if the pesoix check fails, the program should exit
08:18:32 <cpressey> you should get a confirmation if a dialect switch is successful
08:18:59 <cpressey> if you don't you assume the current system doesn't support that dialect
08:19:13 <{^Raven^}> yes a value representing TRUE/FALSE should be returned
08:19:16 <cpressey> and so bos only supports one dialect, that;s ok
08:20:05 <{^Raven^}> all PESOIX compliant software starts in BOS mode
08:20:32 <calamari> I should say esoapi rather than bos.. hehe
08:20:50 <calamari> really cool what you guys have done
08:21:15 <cpressey> still a lot of details to work out :)
08:22:16 <calamari> okay.. so I'd output 00 09 00 to "switch" to EsoAPI dialect, correct?
08:22:48 <{^Raven^}> from a cold start you are already in EsoAPI
08:23:44 <{^Raven^}> cpressy, take a peek at http://jonripley.com/easel/pesoix.zip
08:24:04 <calamari> okay.. so I'm an EsoAPI program, it comes back ater 00 09.. then I output 00 and am stuck
08:25:19 <calamari> wait.. don't want to assume any dialect except esoapi
08:25:51 <{^Raven^}> if you do 00 09 00 from EsoAPI nothing much will happen atm
08:27:54 <{^Raven^}> There will be a modified wrapper for Easel programs which checks for both dialects being available
08:29:09 <{^Raven^}> but after you have checked the all required dialects are available, you can switch between them at will
08:32:27 <calamari> hmm.. right now BOS prints an error message when a bad call is made.. should probably hange that behavior
08:32:52 <calamari> better would just be to ignore the bad call
08:35:33 <{^Raven^}> terminating execution with an error on a bad call would work
08:35:46 <calamari> what if calling the esoapi installation check also put you back into command "00" mode? could that be used to determine whether pesoix is installed?
08:37:01 <{^Raven^}> cpressey has done an impressive job with the specs so far
08:37:19 <calamari> I'm suggesting an alteration I suppose
08:37:23 <cpressey> my 2c... biggest problem right now is that EsoAPI and Easel both assume the esolang has the concept of a "current cell"... not all of them do
08:38:07 <calamari> cpressey: esoapi could be made to work with a stack based language as well
08:38:50 <cpressey> calamari: i'm pushing for working through the i/o channels only. it's the only thing common enough.
08:39:08 <{^Raven^}> i am going to modify Easel to return results via the i/o channels
08:40:15 <{^Raven^}> the main sticking point is that the EsoAPI installation check should return via i/o instead of trying to set a cell
08:40:20 <cpressey> calamari: although in the case of EsoAPI it's very understandable; the code required to (say) read a disk block in via "standard input" probably wouldn't fit in a boot block nicely :)
08:40:40 <cpressey> {^Raven^}: that's a bit more reasonable, yeah
08:41:09 <calamari> cpressey: the main problem with pure i/o was the installation check.. if I read a byte on a normal bf interp, it is going to hang until I press a key
08:41:16 <cpressey> although in any case the input routine turns into "do i have something to return? if so return it. if not then do real input"
08:41:39 <cpressey> calamari: that's sort of unavoidable though
08:41:48 <calamari> cpressey: not the way I did it :)
08:42:06 <cpressey> calamari: that's because you know the language will be brainfuck :)
08:42:21 <calamari> If a language doesn't have a current cell.. then they'd use their stack, or whatever.. up to the language implementor
08:43:18 <{^Raven^}> i feel we are stuck inside the BOS bootstrap
08:43:22 <cpressey> calamari: what would you use in thue? or strelnokoff?
08:44:03 <calamari> not trying to be argumentative
08:44:05 <cpressey> also, i don't like the idea of rewriting every esolang interpreter to work with this
08:44:18 <cpressey> calamari: that only means they're even more esoteric :)
08:44:30 <calamari> just saying that I didn't find pure i/o to be a valid solution because it required the user to push a key in order to exit the program
08:45:28 <calamari> you'd have to rewrite every esolang interpreter to work with it.. afaik :)
08:45:32 <cpressey> ok. i find that acceptable, while i find modifying every interpreter to handle responses (each in a different way depending on the language) to not be acceptable.
08:45:32 <{^Raven^}> you O the installation check, the check code puts the result at the head of the input buffer, you read that single character from the input stream and
08:45:48 <cpressey> calamari: no, actually you don't. that's the brace program i'm working on.
08:47:01 <cpressey> if you want to be friendly, you could output a message first, like: if you are not running under pesoix, press "return" to exit
08:47:43 <calamari> the whole idea was that this would be an extended functionality layer.. it would require a change to the original interpreter
08:48:36 <cpressey> the esobrace program runs another program (the esolang interpreter) and intercepts its I/O
08:49:20 <{^Raven^}> and on systems where esobrace will not work you use a modified interpreter
08:49:41 <{^Raven^}> i am working on the modified interpreter side of things
08:50:07 <cpressey> yeah, it only works on unix right now, freebsd in particular... porting it to windows might be, ehm, interesting. (maybe with cygwin)
08:51:18 <{^Raven^}> but that requires cygwin and i'd prefer the user not to have to download extra software. esobrace will never work on RISC OS, not sure about Macs
08:51:57 <{^Raven^}> that's where the modified interpreter comes into it's own, it will run on any system that a C compiler can target.
08:52:03 <cpressey> should work on modern macs, since they're mostly bsd based. risc os, no clue :)
08:52:30 <cpressey> a modified interpreter is a good approach too; the drawback is of course that it's only one language
08:53:04 <calamari> cpressey: thats also the advantage, though.. because the implementor can make the esoapi calls work in a way consistent with the language
08:54:01 <calamari> cool idea with the forking though :)
08:54:10 <cpressey> resulting in 'n' different ways to use the api, as opposed to one :)
08:54:19 <calamari> since I'm running linux now, it should work nicely
08:55:06 <{^Raven^}> to add PESOIX into any interpreter requires 3 new lines of code and 2 minor changes
08:55:09 <calamari> not really, IMO.. but I don't wish to argue :)
08:55:29 <calamari> (that was to cpressey, sorry my typing is slow)
08:56:19 <{^Raven^}> #include "pesoix.h", pesoix_initialise, pesoix_finalise and changing getchar/putchar with pesoix_getchat and pesoix_putchar
08:56:39 <calamari> anyhow.. glad to see esoapi in there at all, so I feel very honored, thanks :)
08:58:02 <cpressey> calamari: it's not that i want to argue, it's just that there are pros and cons to each approach. i'll consider both sides and write something up, maybe we can get a better idea about it. in the very worst case, pesoix can support both... somehow :)
08:59:17 <cpressey> in the meantime, i need some shuteye :)
08:59:24 <{^Raven^}> calamari, if there was an equivalent to command.com within BOS then you could support Easel
09:00:46 -!- Keymaker has joined.
09:01:40 <{^Raven^}> bed sounds like a good idea even tho it's 9am here
09:02:33 <calamari> I should probably do the same.. need to get up early tomorrow
09:04:46 <Keymaker> seems the there has been plenty of cool stuff happening while i was away..
09:04:51 -!- calamari has quit ("Leaving").
09:05:18 <Keymaker> well, i didn't understand it anyways :p
09:08:09 <Keymaker> ARKE: (typed that capital that you could notice :)) the next BF competition will be there pretty soon, there should be a topic posted on Golf forum in a few days
09:08:31 <Keymaker> and, it is no bfgolf, i just use their forums again :p
09:48:27 -!- Keymaker has left (?).
15:27:56 -!- [^Raven^] has joined.
15:44:34 -!- {^Raven^} has quit (Read error: 110 (Connection timed out)).
16:23:44 -!- [^Raven^] has changed nick to {^Raven^}.
21:05:51 -!- heatsink has joined.
21:30:57 <{^Raven^}> cpressey: http://jonripley.com/easel/ep_specs.txt, contains a write up of my ideas for PESOIX specification so far, please read and comment. Thanks
22:07:38 -!- kipple has joined.
23:15:41 <arke> Contest right now: In the next 24 hours, create an 8086 compatible, DOS Brainfuck interpreter. The source to be interpreted is appended to the end of the executable, and terminated with a 0. 24 hours from now, send me your results by /msg
23:22:16 -!- lament has quit (sterling.freenode.net irc.freenode.net).
23:31:54 <arke> smallest entry wins
23:34:41 -!- lament has joined.
23:37:28 <arke> smallest entry wins
23:40:52 <kipple> Don't do assembler myself, but otherwise an interesting contest :)
23:41:04 <arke> got 4 contestnats, hoping for more
23:44:15 -!- lament has quit (sterling.freenode.net irc.freenode.net).
23:46:29 -!- lament has joined.
23:52:06 <lindi-> arke: how large are they?
23:52:36 <arke> lindi-: oh they havent submitted, I just meant i have 4 people that are doing it
23:52:52 <lindi-> too bad i have physics exam tomorrow :P
23:52:55 <arke> you're welcome to join
23:52:59 <arke> aah, thats too bad
23:53:05 <arke> you can write it now and submit early
23:53:34 <lindi-> nope, but i could write it after the exam
23:54:45 <arke> aah, well thats probably after 24 hours though :(
23:55:02 <arke> actually, since you're in .fi, you probably still have time.
23:55:06 <fizzie> It's 02am localtime here.
23:55:19 <arke> aah, so you have time after the exam
23:55:27 <arke> make sure i have it by 1am your time though
23:57:18 <lindi-> arke: how should it do it's input and output?
23:59:17 <lindi-> BIOS services, DOS services, something else?