Perlbox: A Unix Desktop Written in Perl 292
cascadefx writes "It appears that this programmer has created an Open Sourced Unix Desktop, PerlBox, written in Perl and Tk. I found this posted in response to an article on Perl Monks asking if Perl was obsessed with CGI?. Apparently not. Check it out, it looks pretty interesting." I wonder how fast it runs?
It runs great (Score:1, Funny)
But one bad character in the code and all your files are toast.
It's a speed demon (Score:5, Funny)
About
this
fast
.
Re:It's a speed demon (Score:2, Informative)
Re:It's a speed demon (Score:2)
Speed (Score:2, Insightful)
Re:Speed (Score:2, Funny)
Don't Perl scripts get compiled every time they are run?
I suppose you could say that. In programmerspeak, we call Perl "an interpreted language."
Re:Speed (Score:2, Informative)
Re:Does it matter? (Score:2, Informative)
Non-proc consuming optimizations are done each time also. Perl6 is supposed to allow it to be permanently compiled to a bytecode with extensive optimizations much easier. Currently the methods of creating a pre-bytecoded perl script is (almost) a black magic.
B - The Perl Compiler (Score:3, Informative)
Modules to play with and more info about it:
Re:B - The Perl Compiler (Score:5, Informative)
Damn it, I @#%!$& up the links! Of course it's Overrated since it's broken. Here:
See also perlcompile [perldoc.com], perlhack [perldoc.com], perlguts [perldoc.com], perlxstut [perldoc.com], perlxs [perldoc.com], perldebtut [perldoc.com], perldebug [perldoc.com] and perldebguts [perldoc.com] manpages.
(Note to self: Check those URLs!)
Re:Speed (Score:3, Funny)
Not to be confused with interpretive language which is what 90% of John Katz's work is written in. You know you've switched over when code like
my $wild_speculation = "..." starts cropping up in your code.
Of course, from a distance, Perl and Katz look just as unintelligible. At least Perl makes sense close up.
Perl binaries (Score:2)
Re:Perl binaries (Score:2)
Re:Perl binaries: PerlApp (Score:2, Interesting)
And I can say from experience that it works incredibly well. I've compiled a script which used 20,000 lines of code amongst the various modules I'd built, not including Perl/Tk and the many other CPAN modules I used, and out popped a nice binary which worked just as if run from Perl.
I develop on Linux, but I can use it to generate binaries for Windows users. It opens up a whole new audience for me. I develop quickly on the platform I am efficient on, and all the Windows users know is that they get something with a nice GUI that works as advertised and which was developed in half the time.
Needless to say, I recommend it highly.
Re:Speed (Score:5, Informative)
Yes, but it's compiled into an internal bytecode format, not an executable binary.
In this sense it's more like Java -> Bytecode -> JVM (hence Perl -> Bytecode -> PVM) than, say, C -> Object code -> Native Binary. Not quite, but near enough.
Python has the same property, as do many otherwise interpreted languages. Parrot (the engine Perl 6 will use) is also bytecode based, and probably has more in common with a Java VM, in that it impliments a sort of dynamic-language CPU with registers and instructions, rather than just a tree of tokens the interpreter can easily walk along.
Re:Speed (Score:2)
Re:Speed (Score:2)
Re:Speed (Score:2)
The reason is that suid scripts create a race condition, the time between the interpreter process being created and the interpreter process reading the script can be exploited. Let's say there's a suid script
Dammit (Score:5, Funny)
mod_perlbox (Score:5, Funny)
That way you can access your desktop through lynx [browser.org] at a speed increase of 800%. Just format your urls like this:
http://localhost/desktop/?action=leftclick&xcord=
I wish... (Score:2, Interesting)
Maybe it does and I am just ignorant
Re:I wish... (Score:3, Interesting)
Now, if someone wanted to write a real abstraction layer, maybe one that would let you use either Perl/Tk, Perl/GTK+, or something else... that coule be interesting
Re:I wish... (Score:5, Informative)
See Wx [cpan.org].
Re:I wish... (Score:2, Informative)
Re:I wish... (Score:2)
Re:I wish... (Score:4, Informative)
See Gtk [cpan.org], Gnome [cpan.org], Tk [cpan.org], Qt [cpan.org] and Wx [cpan.org] CPAN distros.
Re:I wish... (Score:3, Informative)
You haven't checked out Wx. It's a Perl module for using wxWindows [wxwindows.org]:
See the wxWindows supported platforms [wxwindows.org].
Re:I wish... (Score:2)
Again, to use the database analogy, that's like saying, "you've got the Oracle module, and Oracle runs on both kinds of systems, UNIX *and* Windows."
Re:I wish... (Score:2, Informative)
http://anygui.sourceforge.net/screenshot
The good news is that while it's possible to port it to Perl, you don't have to if you're willing to wait for Parrot.
Re:I wish... (Score:2)
Re:I wish... (Score:5, Insightful)
Seems a bit trollish, but I'll bite. If I wanted to make a large maintainable and updatable cross-platform app, with lots of time I'd choose Java. If I needed a cross-platform app that needed to be up in little time, and was never gonna be changed, I might chose your PERL with GUI Abstraction.
Honestly, though, I don't think it would "kick java's ass", its like compairing C and C++. Is one better than the other? Depends on how you use it!
A quick and powerful scripting language versus a high level object oriented language?
Apples and Oranges.
Surprisingly, though, they appear to be competing. Parrot, perls next version, contains error handling similar to Java, and Java1.4 added regexp.
Re:I wish... (Score:2)
Parrot != Perl 6 (Score:2)
In this way, I suppose, Perl 6 will be kinda sorta like Java in that it will target a VM, rather than a CPU. The Parrot VM is not exclusive to Perl - from what I understand, idea is that eventually Python and Perl will share a common VM. It's conceivable, I suppose, that some sick bastard could write a Java compiler that targets Parrot.
Parrot isn't finished yet, but there are a few "toy" languages that target it (Jako and Cola, and more recently BASIC).
Re:I wish... (Score:4, Interesting)
I simply copied the parent post's capitalization (not spelling). I've coded large products in both Perl and Java.
BTW - its attitudes like this that make non-technical people afraid to learn technical areas. You sound like a 1337 d00d in #linux-newbies that shouts "RTMFM!" at every question. I don't mind if you argue, but insulting is a sign of elitism, which I didn't think existed in UIDs as low as yours.
Perl is no more or less hard to understand or maintain than any other language if you code correctly. Sure I can make Perl look like line noise, but I can also make it easy to read and maintain.
I wasn't refering to the language itself (or how clean the code is) but the OO of Java vs. the scripting of Perl. Sure, there is OO in perl, but its slapped on and unelegant.
Its arguable, but most coders I know would find a well written, large scale, high level OO application easier to maintain and update than a large scale, powerful scripted application.
Re:I wish... (Score:2, Insightful)
I disagree. I think perl has very powerfull OO capabilities. You pretty much disregard these features, and you compare two conflicting aspects.
most coders I know would find a well written, large scale, high level OO application easier to maintain and update than a large scale, powerful scripted application.
A high level OO application can apply to both perl and Java. Java's OO is not equal to Perls scripting nature. OO != compiled code.
You sound full of bias and purposefull misrepresentation.
Perhaps something like, "Most coders I know like Java better than Perl", is what you are trying to say?
Re:I wish... (Score:2)
From someone who does extensive development in Perl, in both a monolithic and OO environment, I can tell you with much certainty and back up with evidence and examples that Perl's OO is inferior to that of Java and C++. With the exception of the TIEHASH capabilities while working with objects, Perl's OO and namespacing is an inferior implementation.
Because of the way that Perl handles namespaces and symbol exporting, it is much easier to work with C++ or Java for large scale enterprise applications. That's just a fact of life.
Having said that, my language of preference is C. Just plain old C. Followed by C++, then Perl. But that is what I am most happy programming in, and has nothing to do with what language I will choose to develop in. I will pick the best tool for the job.
Perl has a niche that it works exceptionally well in, as does Java, C, C++, Python, etc. While some areas overlap, trying to make a language that does everything is setting yourself up for failure. What is needed in the development world is a standardized object communication layer that does not care what language the objects are in. Pipe dreams, but one can hope.
Out of curiosity, do you work in the industry, or still in school?
Re:I wish... (Score:2)
Please demonstrate or give specific examples how Perl's "unelegant" after market OO implementation results in program design that is more difficult to maintain. Just interested.
I sort like the ability not having to use a OO approach for some programming problems.
Re:I wish... (Score:2)
Please demonstrate or give specific examples how Perl's "unelegant" after market OO implementation results in program design that is more difficult to maintain. Just interested.
[ Note the slience ]
He probably has never even coded in perl. But that won't stop the morons from modding him up as "insightful"; anything that degenerates the status quo is "insightful" here any more.
Re:I wish... (Score:2, Insightful)
It does have it already, check CPAN.
Perl would kick Java's ass as a cross-platform app development language if it did.
No it would not. Perl doesn't even have proper multithreading, how can you pretend that it can compete with Java?
Each tool has it's use. Perl is great for text-processing, but is a toy for most of other uses (and is a damn fun toy, btw). Java is great for boring and usefull stuff like enterprise programming.
The rest of the OS in Perl (Score:3, Funny)
Read my old comment to Subterfuge with Subterfugue [slashdot.org] story: Re:Perl in the Linux kernel? [slashdot.org] There's some info about other parts of the operating system written in Perl: Perl /bin tools, Perl shell and even Perl kernel.
I couldn't find a working link to Perl filesystem
(PerlFS by Claudio Calvelli?),
so if anyone knows it, please post it.
All-Way Flamewar! (Score:5, Funny)
Ruby vs Python vs Perl running Perlbox vs Emacs running everything vs Linux running KDE vs BSD running Gnome vs Windows vs Solaris running Emacs vs OSX running Virtual PC running Activestate Perl running Perlbox...
I think we need big a flow chart for this one.
Re:The rest of the OS in Perl (Score:2, Interesting)
They later rewrote it in C++ though.
funding (Score:5, Interesting)
more open source projects could easily benefit from a funding model like this. There seems to be research money floating around universities (mine included) that could easily go to open source projects; it just may not be the project you want to work on, but hey, getting paid isn't so bad.
Also of note.. (Score:5, Interesting)
Re:Also of note.. (Score:2, Interesting)
Re:Also of note.. (Score:2)
ROX-Filer is my favorite graphical filemanager. Nautilus, GMC, and Konqueror are all way too slow, dfm is ok, but doesn't look as good to me as ROX, and acts a bit strange at times, other file managers are probably well done, but work in file management paradigms I am less accustomed too (i.e. Norton Commander and NextStep style navigation as opposed to classic Mac/Windows icon/folders. Some things I would change if I had the time though, an optional lightweight tree panel on the side (a la explorer), ability to launch multiple files with their default viewers at once, and ability to associate multiple apps for mime types accessible through the context menu (so for images, both gimp and a viewer could be associated). Aside from those little annoyances, it is a much more responsive and clean looking interface than most out there. All these others add tons and tons of features (that no one needs) and use burdensome mechanisms that really slow things down, while ROX has stuck with the KISS principle in an age where most people aim to make things as complex as they can.
Re:Also of note.. (Score:2)
Put ROX-Filer itself in the Send To menu. Then Shift+Menu on the selected files and use that :-)
Re:Also of note.. (Score:2)
Why?! (Score:3, Insightful)
I'd like to see distributing timesharing, so that all these people with *way* too much time on their hands could donate some to us people with sensible projects to complete but not enough time.
Re:Why?! (Score:4, Insightful)
There's place in the world for enjoyable wizardry. That means programming is still an art.
Re:Why?! (Score:2, Insightful)
Most good colleges still teach CS majors how to write an OS, not because they think that the students will have to, as most won't, not because they think it will be anygood, because 99% of the time is a crappy unreliable *Nix clone, but because it tests the limits of a person, (and of course since there is no way for one to ever finish in the time provided it provides a demonstration of the way the world works).
Re:Why?! (Score:2, Funny)
You're not wrong there! This project is like creating a full-scale battleship out of Lego. Ridiculous and slighlty comical - but fascinating at the same time.
Probably (Score:4, Funny)
Re:Probably (Score:2)
That would be an...interesting challenge.
Irony (Score:5, Funny)
Start menu (Score:5, Funny)
______
| @_ |
| $^ |
| $* |
| $1 |
|____|_____________
|($_)|_____________|
(for lameless filter) qsdazewxcqsdazewxcqsdazewxcqsdazewxcqsdazewxcqsda
Re:Start menu (Score:2, Funny)
"(for lameless filter) "
Oh!
I thought it was code for the start menu, in Perl.
right idea, wrong toolkit (Score:4, Interesting)
Re:right idea, wrong toolkit (Score:2)
1. providing a toolbar/taskbar, and desktop icons. (quick and easy ways to get to the applications).
2. integration of applications by using a defined api for communication to other apps (dnd, copy/paste, etc).
3. common look and feel by providing libraries of widgets and widget functionality which developers can use in their applications.
i don't see this being accomplished by using small, easy-to-write, efficient code. what are the advantages of a dynamicly typed language for this type of application (desktop) compared to a down to the metal, c/c++ type language?
Static vs Dynamic: type buzzwords can mislead (Score:2)
Dynamic type-checking is usually done in languages that don't have a strong proof-theoretic interpretation, like the strong interpretation that the purely functional languages have. I know that "dynamic" is one of those wonderful buzz-words thrown around to make things sound fancy, and in most cases a "dynamic" something is better than a "static" something... however, with regards to type systems, "static" type sytems are the way of the future, while "dynamic" type systems are hold hat. Lisp, for example, has been doing the dynamic type thing for decades. I admit though, that this can be a bit misleading too because what was effectively static typing was researched 100 years ago with applications to addressing the mathematical paradoxes of the time. Its not that the age of static or dynamic typing makes one worse than the other... both are old hat, but static typing has far more room to grow and a far bigger payback.
Tell me this: When does a software developer want to catch their program bugs, at compile time or during testing? The answer is easy. If more bugs could be caught at compile time, the software development process would be sped up considerably, time, money, and other resources would be saved. Finally, because finding bugs with a strong static type system is a deterministic logical inference thing, while finding bugs with a dynamic type system is a non-deterministic brute-force rolling of dice thing, one method of error discovery (static) is far more reliable than the other (dynamic).
For those who are interested in strong static type systems, run google searches for "curry howard isomorphism". From there you should stumble upon such important topics as: operational-calculi (lambda-calculus, pi-calculus), proof-theory (intuitionistic logic, linear logic), and category theory. I never said that creating strong static type systems was easy, but it is worth it. The fact is that more information is available during runtime, so for a static type system, lots of math has to be used in order to infer sufficiently accurate types.
Static type checking can prevent function and procedure application errors, datatype errors, deadlocks, race conditions, and even algorithmic time complexity errors (something dynamic systems can't do)!
Buzzwords can be misleading, and in the case of type systems, strong static type systems are preferable to strong dynamic type systems. However, strong static type systems are far more difficult to implement, and the whole area of static type systems is still actively being researched.
type religion can mislead, too (Score:2, Insightful)
Yes. Trouble is: many interactive applications require that information at runtime, and languages like Haskell or Clean do not provide it to programmers.
Dynamic type systems require large amounts of type information and frequently called type checking code to be used during runtime.
Indeed, they do. However, if the application requires that flexibility, it's better if the language defines standard ways of implementing it and the compiler and runtime support it. If they don't support it, the need doesn't go away; instead, developers use string representations, XML, union types, higher-order functions, and a lot of other mechanisms to implement their own dynamic type systems. The result ends up being less safe, less efficient, and less standardized than if it had been built into the language in the first place.
This leads to bloat software bloat that does not exist in strongly statically typed programming languages.
That's wishful thinking, and it's penny wise and pound foolish. You pay a small performance penalty for the type checks, but you get much more reuse and code sharing. In contrast, statically typed languages end up forcing programmers to duplicate a lot of code and hand-code all the dynamic information they might ever need, usually less efficiently and less safely than if the language just had it built in. Furthermore, runtimes for languages like Haskell or Clean, in fact, are usually very similar to dynamic runtimes because they still need some type information; they just don't expose it to programmers.
Tell me this: When does a software developer want to catch their program bugs, at compile time or during testing? The answer is easy.
The answer is easy only for simple-minded people who are religiously in one camp or the other. Static type checking intrinsically cannot replace dynamic typing, no matter how convenient it would be if it could: many type checking problems in interactive systems simply occur long after the program has been compiled.
Static type checking is great for programming-in-the-small. Dynamic typing is essential for interactive applications and programming-in-the-large. And until the ML/Haskell world gets their act together and standardizes support for dynamic typing, in addition to its otherwise excellent static type system, people who need to write large, complex component software are stuck with either fully dynamically typed languages or more modest attempts like Java and C#.
Re:Static vs Dynamic: type buzzwords can mislead (Score:3, Insightful)
A good dynamically typed language (like Python, Ruby, or Smalltalk) will never tell you that you can't do something. With clever classes you can use a library in a way it was never intended. Things like prototype programming are possible, which is absolutely illegal in statically typed languages. Distributed objects are fairly simple to implement. You can wrap things and manipulate objects to adapt your system to the programming environment you may not be able to choose.
The proof is very practical: people do much cooler things in dynamically typed languages than static. I know I'm somewhat biased simply because I spend more in dynamic circles, but I frankly have seen very little in the way of interesting applications coming out of statically typed languages.
Re:Static vs Dynamic: type buzzwords can mislead (Score:2)
So you never have problems with concurrency bugs such as deadlock, race conditions, etc... in large interactive software applications? Give me a break! Having no such errors in your multi-threaded program is allot better than thinking that you don't have such errors, and I don't care how bad ass you think you are as a developer... allowing prevention of such issues at compile time is at least a good sanity test.
Furthermore, catching deadlock dynamically is horribly inefficient and complicated... oh, and as always with dynamic error checking: its too late! How about race conditions? You gonna catch those bad boys during runtime? Heh, oh wait, you are too bad ass to let those sneak into your software.
I realize that you and the other guy that replied seem to only understand type-checking as procedure/function application and data type-checking, but the static variety can allow for types that allow concurrency, but not concurrency bugs (deadlock, race conditions, etc). Also, algorithmic complexity type checking is another new kid on the block that has no equal in the dynamic type checking world...
Perl and XUL (Score:5, Funny)
The only thing really holding me back from using this in my current project (front end management console for the build and test scripts used to QA $AntiVirus_app) in XUL is the lack of a nice drag and drop formbuilder. There's a project to build one - XULMaker [mozdev.org] - but it seems to be making pretty slow progress and be short of people working on it. Anyway, what I was wondering was, where's the Perl bindings? Being able to say :
...
;)
my $g = XUL->new();
$g->set_window(
title=> 'Hello world',
geometry => ([500, 200]),
)
...and so on would be verrrrry cool. And then we could ALL build our own window managers, using Perl. And this post would be on-topic
Re:Perl and XUL (Score:3, Informative)
Re:Python and X11 (Score:2)
There also:
Sawfish [sourceforge.net] which is written using rep, which is a lisp-dialect similar to elisp.
GWM [koala.ilog.fr], another lisp-based WM, dialect is called "WOOL" (Window Object Oriented Language). Interesting and old.
GwML [inria.fr], a WM written in O'Caml. You even get an emacs clone scriptable and written in O'Caml as part of the package!
Tkwm [neosoft.com] doesn't look maintained, for creating WMs (not just desktops, mind you) in Tcl/Tk.
There are straight-up X11 bindings for other languages, which could also be used for creating window managers, with the same method of doing so in C. Ruby and Squeak Smalltalk has them for sure.
A lot of people scoff at the idea of doing this, but frankly, I can't imagine how and why people deal with static, inconsistent environments. Having your parts of your system written in a dynamic language that you can grok means that you can make the changes to your enviornment when you want to. May seem stupid to a lot of computer users and self-proclaimed hax0rs, but for me, that is what makes a computer personal. Same reason people like emacs, I suppose.
i just compiled it to work under a ssh connection! (Score:2, Flamebait)
Seems to work okay.
GNOME: A Unix Desktop Written in C (Score:5, Funny)
javascript errors (Score:2, Informative)
Re:javascript errors (Score:2, Funny)
Camelot Naturals? (Score:3, Informative)
What the hell?
Re:Camelot Naturals? (Score:2)
Just kidding folks, I think it's funny watching people argue about that sort of lameness sometimes, but in all honesty it gets boring.
Re: Story made up to get traffic? (Score:2)
Re:Camelot Naturals? (Score:2)
"Editorial Bias?? We don't even read the stories..." ~CmdrTaco
Re:Camelot Naturals? (Score:3, Informative)
Something really funky is going on. I type in www.perlbox.org, and the page that loads up is www.camelotnaturals.com
What the hell?
I think they removed the entry from the virtual hosts once the ISP saw the slashdotting. Apache (it's running apache 1.3.20) defaults to the first virtual host if a entry isn't found for the domain being requested. www.camelotnaturals.com is probably that entry.
Looks like they've realized it and replaced it with a blank page. I don't think it was meant as a deceptive advertisement or anything like that.
Site redirection? (Score:2, Informative)
Magius_AR
slashdot frontpage spamming adverts? (Score:2)
. .
is it only me, but when I clicked through to the frontpage link PerlBox.org [perlbox.org] I'm getting redirected to http://www.camelotnaturals.com/ a site selling herbal bath salts????
seriously, mod me down if I'm wrong (I can take it :) but this is silly, has someone effectively spammed the front page?
Can someone else check?
Could someone have switched on a redirect after the editors posted the story, for profit? Did the editors check?
Somehow I've checked this now 6 times, and I still have a problem with disbelief . . .
* To the Editors (Score:2)
It works fine if you just use the latter node_id parameter, as here [perlmonks.org]
It would be nice to see more links to PerlMonks, and Perl articles in general. As far as I know CPAN is probably the biggest group of modules built by a single programming community which actively mixes and matches them. While there isn't one brain to it, PM is the best place I think to talk about them. Thanx
mattr
Re:perl is teh sux0rz (Score:2, Informative)
Re:perl is teh sux0rz (Score:3, Insightful)
gosh, i'm tired of hearing this.
if you develop some actual coding discipline, you can write very maintanable code in perl. use generous ammounts of whitespace, develop style rules for yourself and stick to them religiously, use descriptive full word variable names, separate compound statements into easier to understand (and easier to insert stuff between) smaller ones and of course take advantage of perl's '-w' and 'use strict' features. and if you think something still isn't clear, then for pete's sake comment it! don't blame poor coding practices on the language itself. you can just as easily write nasty unreadable code in c.
Re:perl is teh sux0rz (Score:2, Insightful)
The problem with Perl is that from the very first moment it was pushed as the "there's more than one way to do it" language, and that's *WRONG* (very big IMNSHO here, of course) because it leads to confusion.
You could easily write mantainable code in Perl, but what about other coders? Could you take a job that requires Perl code (written by others) maintenance and be sure that you won't have problems?
Ok, I agree about other languages obfuscation (say C and C++), but if it was for me I'd choose a more self documenting language. In the "scripting" arena today I really like Ruby: powerful as Perl and Python, but much easier to learn (and read!).
Re:perl is teh sux0rz (Score:2, Interesting)
hell yes! i am the tech lead on a perl project which hit 100K lines of code and doesn't look like stopping anywhere before 150K. the design is *very heavily* OO (one could directly translate the object model into java no sweat) and follows the MVC paradigm to the letter (there is only a single 100 line script which drives everything).
perl can be every bit as maintainable as any other language *as long as* one is/enforces discipline. i think at times perl can be more maintainable than, say, java, simply though its expressiveness and brevity. i mean, java can be so frickin verbose sometimes...
which leads me to the conclusion that people who truly think that perl is inherently unmaintainable must be crap programmers.
Re:perl is teh sux0rz (Score:2)
Thou shalt use strict
Thou shalt use -w
Thy subs shall fit in one page.
Thy programs shall produce output from pod2txt
Subs used in more than one program shalt be included in a module.
That and when i was writing most of my code I was also teaching one of the Jr. Admins Perl so my code was commented ad naseum (I really think that my scripts were 50% or more of just comments.)
It made me feel all warm and fuzzy when my acolyte e-mailed me a year after I'd left and told me that the Sr. SA had taken one of my scripts and converted it to a module in 1/2 a day to extend one of their applications.
Re:Toy (Score:3, Funny)
Like a desktop written in Perl?
Re:That perlbox.org Site apears to be somewhat bug (Score:2)
Re:Don't You People Ever Sleep (Score:2, Redundant)
It turns out the webserver was written in Perl, too.
Re:Don't You People Ever Sleep (Score:2)
FYI: It's "Yogi", not "Yoggi"...
Yogi Berra [baseball-reference.com]
Re:Why tk? (Score:3, Interesting)
However -- the nice thing about Tk is that the widgets are
_extremely_ customisable. A bit of tweaking of the widget options and you can make it look pretty much like anything.
(Obviously within reason -- you can't change widget shapes, ferinstance).
All my Tk apps, for example, have the JFC/Swing 'Metal' look 'n feel, for a bit of consistency across Java and Tcl/Tk apps.
The Sawfish wm is written in a Lisp dialect (Score:2)
Re:debian (Score:2)
And as for compiling it... it's perl! You don't have to compile anything yourself.
Re:debian (Score:2)
That can't be Perl code! (Score:4, Funny)
Re:Source Code Here! (Score:2, Funny)
shell# perl -MMOD::Desktop -e 'desktop_app while(1)'
Re:ORA PerlBook? (Score:2)
Ummm...the camel [oreilly.com]...I have this sneaking suspicion that O'Reilly is going to pick the camel [oreilly.com] as the animal for their perl books [oreillynet.com].
"Hello, Navi." "Hello, Lain." (Score:2, Interesting)
Steve
Re:Watch out Internet Explorer Users (Score:2)
Re:Show some proof? (Score:2)
And what the hell am I doing responding to some anonymous accuser anyway? (I may make it sound like I wrote the site -- I didn't) . And why the hell am I expecting any better from slashdot?
Re:Watch out Internet Explorer Users (Score:2)
Re:web viability (Score:2)
Re:SAME IP!!! Redirect to CamelotNaturals.com (Score:2)