IRC log started Wed Apr 28 00:00:00 1999
[msg(TUNES)] permlog 1999.0428
-:- AlonzoTG [Alonzo@client-151-200-125-70.bellatlantic.net] has joined #tunes
!Hyrwork:*! yey, 5 more hours and I go home! :( damn grave shift
-:- NetSplit: varley.openprojects.net split from koontz.openprojects.net [04:31am]
-:- BitchX+Deb1an: Press Ctrl-F to see who left Ctrl-E to change to [varley.openprojects.net]
-:- Netjoined: varley.openprojects.net koontz.openprojects.net
-:- ^lilo [lilo@varley.openprojects.net] has joined #Tunes
-:- Downix [down@survivoronetwothree.ne.mediaone.net] has joined #tunes
<Downix> Hey-lo all
-:- Downix has changed the topic on channel #Tunes to: reflextive OS's at it's best:  http://www.tunes.org
-:- Downix has changed the topic on channel #Tunes to: reflective OS at it's best:  http://www.tunes.org
<Downix> ok
-:- NetSplit: varley.openprojects.net split from koontz.openprojects.net [04:45am]
-:- BitchX+Deb1an: Press Ctrl-F to see who left Ctrl-E to change to [varley.openprojects.net]
-:- Netjoined: varley.openprojects.net koontz.openprojects.net
-:- ^lilo [lilo@varley.openprojects.net] has joined #Tunes
04:50am
-:- SignOff Downix: #TUNES (time for work)
-:- Plundis [plundis@abraham.dataklubben.dmz.thunmanskolan.uppsala.se] has joined #tunes
-:- Plundis [plundis@abraham.dataklubben.dmz.thunmanskolan.uppsala.se] has left #tunes []
!NickServ:*! netgod used GETPASS on d
-:- Fare [rideau@quatramaran.ens.fr] has joined #Tunes
!netgod:*! upgrading mccaffrey to 2.10.05
* AlonzoTG/#tunes greets "Salutations Fare!" :-)
<Fare> ole, Alonzo!
11:20am
<AlonzoTG> om
11:40am
-:- SignOff AlonzoTG: #TUNES (Have Nice Day :))
-:- hcf [nef@me-portland-us1002.javanet.com] has joined #tunes
!netgod:*! becquer calvino clarke dickson norton and vinge will be upgraded to 2.10.05 presently
!netgod:*! this may cause some, shall we say, discontinuity in the net
-:- NetSplit: clarke.openprojects.net split from koontz.openprojects.net [01:14pm]
-:- BitchX+Deb1an: Press Ctrl-F to see who left Ctrl-E to change to [clarke.openprojects.net]
!netgod:*! thanks for your patience
-:- _QZ [brand@p0wer.qzx.com] has joined #tunes
-:- Netjoined: clarke.openprojects.net koontz.openprojects.net
-:- Tril [dem@sloth.wcug.wwu.edu] has joined #Tunes
-:- abi [nef@bespin.cx] has joined #Tunes
-:- mode/#Tunes [+o Tril] by ChanServ
<_QZ> hello
<abi> what's up, _QZ
01:50pm
<Fare> what's down, abi?
<abi> fare: i haven't a clue
<hcf> abi: what's down?
<abi> down is below up
<Fare> abi: what's up?
<abi> fare: no idea
02:10pm
<hcf> abi: what's up?
<abi> up is probably above down
<Fare> nice girl
* Fare/#Tunes is looking for a sign of the elder in ascii art...
<_QZ> elder?
02:20pm
-:- AlonzoTG [Alonzo@client-151-200-120-87.bellatlantic.net] has joined #tunes
<hcf> hoy AlonzoTG
02:40pm
* Tril/#TUNES is back from the dead. Gone 44 hrs 34 min 45 secs
<Fare> trril!?!?
<AlonzoTG> om
02:50pm
<Fare> mu
<AlonzoTG> I was trying to booleanize a BST...
<AlonzoTG> :P
<AlonzoTG> but I wymped out..
<AlonzoTG> :|
<Tril> oops
<Tril> hi fare
>>> Tril [dem@sloth.wcug.wwu.edu] requested PING 925337119 388567 from #TUNES
-:- SignOff Tril: #TUNES (changing servers)
-:- Tril [dem@sloth.wcug.wwu.edu] has joined #TUNES
-:- mode/#Tunes [+o Tril] by ChanServ
>>> Tril [dem@sloth.wcug.wwu.edu] requested PING 925337202 995005 from #TUNES
<hcf> AlonzoTG: BST?
-:- SignOff Tril: #TUNES (changing servers)
-:- Tril [dem@140.160.164.200] has joined #TUNES
-:- Tril_ [dem@bespin.cx] has joined #TUNES
>>> Tril [dem@140.160.164.200] requested PING 925337301 925435 from #TUNES
>>> Tril_ [dem@bespin.cx] requested PING 925337270 134560 from #TUNES
03:10pm
<Fare> lkh
<Tril_> what's up
<AlonzoTG> gronk!
<AlonzoTG> :)
<AlonzoTG> I'm making a sekund attempt...
<Fare> abi: what's up?
<abi> somebody said up was above down
<Fare> Tril: I'm writing three papers on the formal notion of an implementation, how to apply it to implementation of failsafe persistent/distributed memory, and how to use it to formalize the notion of reflective systems.
<Tril> oh
<Tril> you mean an implementation for tunes, or an implementation of anything in general?
<Tril> did you read either the arrow draft or my specs yet?
<Fare> implementation in general
<Tril> so what's the notion of a specification? Isn't that the counterpart?
<Fare> in the framework of operational semantics, aka transition systems, aka categories, aka rewrite logics, aka abstract state machiens
<Fare> maybe an adjunct notion, category-wise?
<Fare> dunno, I have to buy and read MacLane's "CAtegories for the working mathematician" to be sure
<Tril> <Tril> did you read either the arrow draft or my specs yet?
<Tril> what you're doing sounds useful.
<Tril> I'm working on my specs.
<Tril> I need to read the arrow draft before posting again to the list. Brian will fry me otherwise.
03:20pm
-:- SignOff Fare: #TUNES (Ping timeout for Fare[quatramaran.ens.fr])
-:- Fare [fare@balance.wiw.org] has joined #Tunes
<Fare> hum
<Tril> yes or no
<Fare> had to log on another account
<Fare> yes or no what?
<Tril> have you read the arrow draft or my specs?
<Fare> I read an old version of your specs
<Fare> and I skimmed along an old arrow draft
<Fare> rereading the specs just now
<Tril> it gets kind of fuzzy down near the Root Type, i'm still writing that
<Tril> and skip entirely the reference section at the end
<Tril> well, tell me if I got quotient right anyway
<Fare> problem with IDs: in a distributed system with failures, IDs are revealed when published on the wire and have to be honored forever
* Tril_/#TUNES is away: (Auto-Away after 10 mins) [BX-MsgLog Off]
<Tril> no. the owner of the ID is allowed to mass-notify all clients of the ID to start using a new ID
<Fare> hey, my server was up 73 days
<Tril> maybe I should put that in
<Fare> Tril: in presence of failures/disconnections/etc, you CAN'T reliably notify every clients
<Fare> unless your object has a static timeout
<Fare> (and you have reliable enough clocks)
<Tril> if there is a failure, you can't use the object indicated by the ID anyway.
<Fare> which makes your system fragile.
<Tril> uh, i'm not worrying about distributed networking right now.
<Tril> whatever mechanism YOU have in mind for dealing with these failures can be added later.
<Fare> that's one thing I discuss in my article#2 on implementation: what kind of failures do you take into account, and what kind of properties do you want to preserve despite these failures?
<Tril> however in my system just about any abnormal situation will be dealt with by a type error.
<Fare> oh, without distribution, things are sure simpler.
<Fare> Tril: sometimes, you want failures to be transparently taken care of
03:30pm
<Fare> power shut down of a a compupter, for instance, is such a failure
<Tril> you are still thinking of implementations. that's fine, but not useful right now. I'm talking about metasystems, and failure isnt inherently at a meta level.
-:- SignOff hcf: #TUNES (Leaving)
-:- ochoa [sscdatanet@infovia103.datanet.es] has joined #Tunes
<Fare> oh, before we can specify the metasystems, we must understand implementation
<Fare> my thrid paper is on metasystems
-:- ochoa [sscdatanet@infovia103.datanet.es] has left #Tunes []
<Tril> hmm
<Fare> and how to dig through the existing "reflective" crap, once you've understood it all
<Tril> ?
<Fare> the idea is that to have specified things, you must, at every time, consider a (varying) "base level".
<Fare> at any given time, you specify what you want in terms of a given programming framework.
<Fare> (or multiple given frameworks)
<Tril> ok
-:- ochoa [sscdatanet@infovia103.datanet.es] has joined #Tunes
<Fare> and then, you want your actual concrete implementation to fulfill all these abstract specifications
<Fare> at the same time
<Fare> this relates directly to aspect-oriented programming.
<Fare> Now, the real interesting thing is in the metaprograms that will realize the implementation
-:- ochoa [sscdatanet@infovia103.datanet.es] has left #Tunes []
<Fare> the specification of these metaprograms is that they should respect the constraints given by the abstract aspects
<Tril> no, the interesting thing is the typesystem, which will detect contradictions in the specifications :)
03:40pm
<Tril> i'm glad you want to do the metaimplementation
<Tril> but isnt "implementation" just a translation? From a spec language into a low level hardware interaction language?
<Fare> depends on what exactly you call "implementation": the actual translated code, the code that does the translation, or something else, etc
<Fare> at one time, you need give precise names to things
<Fare> and english is no more the right language
-:- tcn [tcn@cci-209150250120.clarityconnect.net] has joined #tunes
<Fare> tom!
>>> Tril [dem@140.160.164.200] requested PING 925339596 187618 from #TUNES
<Fare> Tril: your text is correct, but deserves more the name of "design notes" than of "specifications"
<Tril> why's that
<Tril> well, it's not formal , sure
<Fare> well, it specifies less than, say, RScheme's internal documentation
<Fare> (it's not a reproach)
<Tril> well, I don't disagree
<Tril> I call it a specification because someone else may implement it other than me
<Tril> and I hope it may approach a specification as I revise it..
03:50pm
<tcn> reading my email :)  lots of it..
<Fare> <aol>me too</aol>
* Tril/#TUNES ignores the tunes mail
<Tril> I'm not allowed to post until I read the arrow draft
<Tril> tcn: are you getting private email about retro?
<Tril> fare: thanks for the support for my design notes, then.
<tcn> Tril: yeah, maybe 1 a day now
<Tril> tcn: from core? :)
<tcn> Tril: yeah, got one from him
<Tril> he's been logging on a lot
<tcn> I was overwhelmed by that Arrow paper.. I don't have the math/CS background for that. Whatever happened to English?
<tcn> ;)
<Fare> brb
-:- Fare is now known as FareWell
-:- Fare [rideau@quatramaran.ens.fr] has joined #Tunes
<Tril> It's a lot better than the babble he used to be posting to the mailing list
<Tril> I think the arrow paper is very clear.  It has to be advanced though, because of the topic he's talking about...
<FareWell> yeah, the old draft I read was much clearer, but there were still dark zones
<Tril> that's the one I sent you, right?  that's the one i read too..
<FareWell> oh, on the other hand, I was disappointed by the english stuff about polycontextural logics
-:- SignOff FareWell: #TUNES (Connection reset by pear)
<tcn> Maybe it would be more understandable if I s/Arrow/Foobar :)
* Fare/#Tunes is there
<Fare> tcn: sure
<Tril> maybe you should mail the author.
<Tril> with your comments.
* Fare/#Tunes puts on glasses and sees better
<Tril> i'm on a roll , i'll read the new one soon
<Fare> btw one of the first tunes apps should be a tex replacement embedded into the tunes language
<Fare> and having it work dynamically will replace X, too
<tcn> tex-compatible, or a fresh start?
<Fare> fresh start
<tcn> good, that's what I had in mind too
04:00pm
<tcn> not that I ever used tex
<Tril> do I have to learn tex before we make that?
<tcn> no
<Fare> but feature-wise superior to TeX
<Fare> Tril: no, although it would be great to have TeX gurus to assist at one time
<Fare> I know quite a few from my school, who might help once we have a plausible promise...
* tcn/#tunes is building a macroprocessor
<Fare> uh??? why?
<Fare> don't!
* Fare/#Tunes remembers painful experiences using m4 as a macroprocessor frontend to as86 in pre-nasm days
<tcn> as opposed to a microprocessor :)
<Fare> oh
<Tril> transistors?
<abi> transistors are Collector Base Emmiter
<Fare> ever heard about MISC technology?
<tcn> haha
<tcn> yeah
<Tril> fun.
04:10pm
<tcn> I'm using a 4-bit word size :)  16 instructions
<Fare> abi: can you explain NPN and PNP transistors? and teach me how transistors have evolved since the early 80s?
<abi> i haven't a clue, fare
-:- ochoa [sscdatanet@infovia103.datanet.es] has joined #Tunes
<tcn> hola
<ochoa> hola hola
<tcn> Fare: *have* they evolved since the 80's?
<Tril> have we met?
-:- SignOff ochoa: #TUNES (Client exiting)
<Fare> tcn: I heard that technologies after cmos (like hicmos, chmosN, etc, etc) were "different".
<Fare> all I know was read in books from the early 80's by Rodney Zaks
<Fare> (I took a course when at school, but learnt nothing)
<Tril> why did CL have to define T as a constant? It's the most frequently used symbol for custom use!
<Fare> (I mean, nothing new, except for general rules on power consumption and why ROM was slower than RAM -- for purely political reasons)
<Fare> tril: historical reason!
<Tril> '(q r s t u v)  <-- do something to this list, and it won't work
<Tril> because there's a T in it!
<Fare> you can do a lot of things to the list, without hitting the "t is a constant"  ""limitation""
<Tril> (eq 'historical 'dumb)
<tcn> that's why scheme uses #t
<Fare> Tril: not forcibly dumb.
<Fare> Tril: the problem is, the LISP tradition failed
<Fare> (which is explained in the last chapter of "Hackers")
<Tril> in my assignemtn last quarter, I used the list to choose lambda symbols. No go.
<Fare> as my mom said: they were punished for their greed and their arrogance.
<Tril> (lambda (t) ..)   <-- WRONG
<Fare> oh, lambda(t) is wrong indeed!!!
<Tril> lambda(a) through (s) worked fine.
<Tril> does that have something to do with why everyone uses C these days?
04:20pm
<Tril> (not the T thing, the greed and arrogance)
-:- SignOff AlonzoTG: #TUNES (Have Nice Day :))
<Fare> Tril: yes, that does
<Tril> I'm unaware. What happened?
<Fare> the LISP hackers failed because they went proprietary
<tcn> they formed Symbolics to build Lisp Machines
* Tril/#TUNES looks at rms
<Fare> and the last free LISP hackers, RMS, finally decided to do GNU instead.
<tcn> and all the hackers (except rms) left MIT to join Symbolics
* Tril/#TUNES looks at esr
<Fare> no, half of them went do LMI
<tcn> oh yeah, because they had a disagreement :)
<Fare> (and associated with TI, iirc)
<Fare> a _big_ disagreement
<tcn> if LMI had been more successful than Symbolics it might have turned out better.
<tcn> but I guess, greed wins
<Tril> is that the disagreement that caused scheme to be invented?
<Fare> well, most of them at Symbolics, a few at LMI, Stallman in the middle only remaining at MIT, and everyone lost.
<Fare> Tril: no, scheme was invented earlier
<tcn> The disagreement was over business practices
<Fare> but the disagreement certainly had an effect on scheme chosen over LISP in academic settings
<Fare> s/ chosen/ being often chosen/
<Tril> this was all in Levy's Hackers? I guess it's been a while since I read it last.
<Fare> tcn: over management too -- a small company led by hackers vs a big company led by suits
<Fare> Tril: in the appendix/last part
<Fare> Tril: I also learnt small parts of the latter story by reading comp.lang.lisp and a few lisp mailing lists
<Tril> i dont have a copy
<Fare> So, the historical thing wouldn't be a serious problem had the traditional been kept lively
<Tril> well, if you want a business that isn't primarily about money, I say start a non profit organization.
<Fare> the problem is, they propritized the tradition, so it went mostly dead
<Fare> (although it is surviving in many places by its sheer superiority over the surrounding crap languages)
<Tril> well I will go now.
<Tril> bye all!
* Tril/#TUNES  is away: (afk) [BX-MsgLog Off]
<Fare> Tril: bye!
<tcn> later
<Fare> later!
<tcn> so, how's it going, fare?
<Fare> for me in general, see the tunes irclog
<Fare> for our problems in particular, I haven't done a thing :( :( :(
<tcn> I might have more time in a few weeks
-:- Fare is now known as FareWell
-:- Fare [rideau@quatramaran.ens.fr] has joined #Tunes
-:- Fare [rideau@quatramaran.ens.fr] has left #Tunes []
04:30pm
<FareWell> tcn: want me to do something particular?
<tcn> w/ Scheme?
<FareWell> fer instans
<tcn> hmm.. Retro would be a lot closer to Tunes if it had an IDE driver and persistent store
<FareWell> yup, even if it is through BIOS and with other interrupts disabled
<FareWell> (as in, "one shot persistence" vs "realtime persistence")
<tcn> hehe
<FareWell> core's clementine should have stuff. Let's nag core!
<tcn> After the floppy driver, I think IDE will be easy
<FareWell> is the floppy driver working?
<FareWell> the size of the linux ide driver isn't a good omen
<tcn> Yeah.. but it's not being used currently
<tcn> Linux is bloated
<FareWell> yeah, but it supports 666 different chipsets
<tcn> Maybe it's not put together very nicely
<tcn> Man, I can't wait to get away from PC's and the proliferation of incompatible hardware!
04:40pm
* tcn/#tunes wonders what ever happened to standards...
<FareWell> "every technique is designed, used, important, obsolete, standardised, then understood"
04:50pm
<tcn> well I'm gonna get off the phone while I write this long email
-:- SignOff tcn: #TUNES (tcn has no reason)
-:- SignOff FareWell: #TUNES (Back to the Tunes OS project -- /whowas FareWell)
-:- Fare [rideau@quatramaran.ens.fr] has joined #Tunes
05:00pm
-:- Downix [down@survivoronetwothree.ne.mediaone.net] has joined #tunes
<Downix> Hey all.
05:50pm
<_QZ> hello
<abi> hi, _QZ
06:30pm
-:- GMOL [gmol@24.66.11.51] has joined #tunes
<Downix> hey
<GMOL> hey, real name?
<Downix> Call me Nate
-:- GMOL [gmol@24.66.11.51] has left #tunes []
07:20pm
-:- krz [krz@sloth.wcug.wwu.edu] has joined #tunes
-:- SignOff krz: #TUNES (time to visit the habitrail tube)
<Fare> hello
<abi> hoy, Fare
09:20pm
-:- SignOff Downix: #TUNES (Leaving)
-:- hcf [nef@me-portland-us214.javanet.com] has joined #tunes
-:- SignOff hcf: #TUNES (Leaving)
-:- hcf [nef@me-portland-us310.javanet.com] has joined #tunes
-:- SignOff hcf: #TUNES (Leaving)
!mccaffrey.openprojects.net!! Remote CONNECT drexelhill.pa.us.opirc.nu 8005 from lilo
!koontz.openprojects.net!! Remote CONNECT norton.openprojects.net 8005 from lilo
!koontz.openprojects.net!! Remote CONNECT zheng.openprojects.net 8004 from lilo
!carter.openprojects.net!! Remote CONNECT zheng.openprojects.net 8005 from lilo
!carter.openprojects.net!! Remote CONNECT zheng.openprojects.net 8004 from lilo
[msg(TUNES)] newlog 1999.0429
IRC log ended Thu Apr 29 00:00:01 1999
