| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> yo llama32
<1> ... You have to quit IRC in order to switch window managers? WTF?
<0> holzplatten: why do you kill irc for a wm-switch ?
<0> (sounds kinda unnecessary for me)
<1> r0nny: Actually, there are scenarios under which it is necessary. Such as when killing the WM process kills out your X session.
<0> nyef: i have my wm as main app, still i can easyly switch it by telling it to replace itself by another wm
<1> Heh. Does it obey ICCCM when it comes to manager selections?
<1> Is a doubly-linked list the easiest way to implement an LRU queue (for disk buffers or page eviction, for example), or are there some other techniques I should look at?
<2> scheme is still creeping me out...
<1> Too well thought-out?
<2> too... scheme...
<1> Heh.
<2> im in the mood for writing a windowing system
<2> and im in the mood for doing it in scheme :D
<2> what worries me most is memory consumption...
<2> apparently scheme & lisp tend to eat more RAM than java with the munchies
<1> Appearances can be deceiving.
<0> llama32: guess where "lisp programmers know the vaule of everything, but the cost of nothing" is from
<1> I wrote an emulator in Lisp, back before I knew what the hell I was doing with the language. When it took about six hours to run less than 15 seconds of emulated time I asked for optimization help.
<1> Turned out that the problem was that it was allocating memory like there was no tomorrow.
<2> haha...
<1> Within a few days, it didn't allocate -any- memory in the main loop.
<2> reminds me of once i got this maths problem at school... i made a BASIC program and had to leave it running overnight...
<0> lol
<1> And was more than fast enough to continue developing.
<0> do not use stupidly slow languages for stuff needs speed
<2> i only knew basic at that point
<2> actually no
<2> i knew pascal too
<0> and why didnt you use it ?
<1> Lisp can be extremely fast, you just need to know how to tell it enough about your program that it can optimize it properly.
<0> yeah
<2> but not realising that maths teachers got taught pascal in uni, i figured i'd better put it in basic
<0> lol
<1> And there are a number of things you can do to make it not allocate memory for things.
<0> still - there is stuff where listp just cant be as fast as necessary
<0> eh lisp
<1> r0nny: Oh?
<0> nyef: ?
<1> r0nny: Examples, please?
<0> nyef: dont make me think of this now - easy examples are to easyto break, and i dont want to think of a complex one
<1> And speed is a -lame- reason to pick a language these days, given how fast modern CPUs are.
<2> speed doesn't seem to be an issue - it's memory usage i'm worried about... RAM usage is proportional to swapping which is inversely proportional to responsiveness
<2> it's *highly* noticable with java programs here [256mb ram]
<0> nyef: there are science uses, where being really fast matters, cause stuff is an like millons of times and calculations need few days each
<1> 256mb for the -working set-?
<2> working set?
<1> Is that 256mb for the entire program+runtime+data, or is that just the bits that get used?
<2> no sorry i meant i have 256mb of ram - so memory usage is noticable
<1> Ah.
<1> The thing is, your allocation profile is going to depend heavily on the nature of your program and host environment.
<1> And I'm not sure there's any real way to "prove" that one system is better than the other in terms of memory use, as they engender different styles of program.
<2> mm pie
<1> Pecan pie?
<2> im thinking of using scheme to write a compiler for a language with similar syntax to scheme but different nature [more like D]
<1> Ah.
<1> Writing compilers in Lisp-type systems can be quite easy. Parsing is a lot easier, for starters.
<2> imagining how the compiler would work is so much easier than imagining it written in anything else... like you'd just have a big list, that you could p*** to a backend specified on the command line incredibly easily
<0> but optimizing for speed/memory usage is lots harder
<1> Oh, no. The compiler is slow. Whatever shall we do?
<2> :o slow... you mean... like GCC?
<0> gcc isnt fast
<2> language will be a combination of lisp and D... infix or prefix notation, where you can either write (1 + 2) or (+ 1 2), (a if b c) or (if a b c) [however much the former looks like crap]... type information encouraged but not mandatory... not sure wether i want a traditional object system or a CLOS-like one... mainly worried about runtime lookup speed of CLOS - having 1000 variations on the method 'toString' is more likely than any one cl*** o
<2> wning 1000 methods
<0> sound pretty bad
<2> though im thinking of using an [optional?] obj-c compatible object system, for the GNUstep [whatever capitalization they use] community
<1> If you "seal" your system so that no further modification can be made, there are all -sorts- of tricks you can use to optimize method dispatch.
<1> Even if you don't, it's not so bad.
<0> i'd just go with c++ in kernel, python in userspace, and a nice c++ to python reflection api that works like boost::python
<2> D IN KERNEL!
<2> D D D
<0> i allready told ya i dont like d
<2> at one point i began translating Prex into D... i sorta got bored with the pointlessness though - was only at that point taking advantage of modules - no OO or anything
<0> Prex ?
<2> microkernel-ish embedded-ish OS
<2> prex.sf.net IIRC
<0> btw . how much of a rtl does d need, to utilize all language features
<2> i never got far enough to use a lot, so im not really sure
<2> and it is undocumented [GNU D runtime might have documentation/readable source though]
<0> does the array stuff work out of the box ?
<2> im not completely sure - i was translating C module-by-module, keeping the code compatible with other still-C modules, so i didn't do any D array stuff
<0> could you give it a try ?
<2> yep, just a sec
<2> i know exceptions need runtime support, and array bound errors throw exceptions so i get the feeling it would need runtime, though you could maybe turn off the checks
<0> llama32: then it wont work at all, cause there is no kernel-save exception-lib yet
<1> ... Words fail me. I'm looking at some of the menuet documentation, and... Ugh.
<0> menuet is sick as hell asm voodoo
<0> llama32: in a microkernel you might have a chance tough
<2> ahh: pie.d:(.gnu.linkonce.t_array_3pie+0x11): undefined reference to `_d_array_bounds'
<2> there are some D kernel projects
<0> im soo glad i have c++
<2> one of which mentioned that atm they are porting the runtime to kernel mode
<2> you can still use normal C arrays anyway
<0> normal c arrays arent save
<0> also oop with c is hell
<2> still, it's better than C - faster compile times, module system, documentation system, functions with same name but different arguments, ...
<0> lol - dont compare compile times - gcc is really slow
<2> damn straight
<2> might as well send your program in a capsule into space and wait for some aliens to find it, translate it and send back the binary
<0> that was twice as fast as gcc
<2> hahaha
<0> fortune is unfair "The 80's -- when you can't tell hairstyles from chemotherapy."
<0> list installed all fortune cookies i could find
<2> huh? rephrase?
<0> re
<0> llama32: i installed all quotes i could get for the fortune tool
<2> hmmm
<2> there is an objc bridge for chicken scheme... i wish i could ***ume it worked with the gnu runtime...
<3> r0nny: Does that mean that this fortune is true for your hairstyle? :-)
<0> marco_g: no - but a few years ago it kinda was ( i was drunk - and fortunately i only managed a horrible broken hairstyle - im glad i did nothing permananent
<3> :-)
<4> hi people
<2> AAAAAAAAAAAAAAARGH I HATE UBUNTU
<2> nothing, i repeat nothing, works
<2> lets see... gnome - it works
<2> ummmm firefox works
<2> gaim works, as much as gaim ever does
<2> that's it.
<1> Ooh. That's no good. You need at least emacs, xchat, and xmms for a usable system.
<2> Compiler Time(s) lines/second MBytes/second
<2> TinyCC 0.9.22 2.27 859000 29.6
<2> GCC 3.2 -O0 20.0 98000 3.4
<2> KDE works - as much as someone installed it, opened konqueror, noticed something came up on the screen, went back to gnome and concluded that KDE and it's applications were well tested on ubuntu
<1> ... WTF? Nasm has -no- obvious documentation.
<5> yahoo
<1> (And by "obvious", I mean "on the website, mentioned in the manpage, or as an installed info file.")
<2> use FASM
<2> it's written in ***embler at least, so you know it's developers know something of asm
<1> ... It's also not obviously in portage...
<5> italta la vista
<2> did somebody just mention the next version of windows? KILL gr00ber!!!! KILL KILL KILL!
<3> Who cares about windows?
<3> Enough to hope someone dies...
<5> llama32
<5> he can go spit somewhere else
<2> hehe
<2> i hate linux/unix almost as much as windows actually
<2> and macosx on about the same level as windows... but hell its made by apple and they name releases after kitties, so it's sorta cute...
<6> llama32 is the only one loving Plan9 - even if it doesnt work in the real world...
<2> i dont love plan9, never even used it, i just like the everything-is-a-file concept, even if i would implement it quite differently
<2> yeah old mac -> good
<2> but with osx it just lost the simplicity and added nothing
<1> With PPC it lost the simplicity, really.
<2> i have an old mac... 16 colour screen *drool*
<2> i must say it's a tad neglected
<1> I see your 16-colour screen, and raise you an SE/30. Black-and-white!
<1> (Okay, my SE/30 is actually dead, but that's not the point.)
<2> mine can do b&w too!
Return to
#osdev
or
Go to some related
logs:
#ubuntu
getbyhostaddr
vim column copy
#ldap
#mysql
#sed
ntfs explorer
unmount ipod ubuntu device is busy
earlykdm suse compiz
#fedora
|
|