>> I don't know if you planned on addressing threading in D, but many "new" languages are offering threading as a builtin library.  I don't recommend
>going
>> down that route though :)
>
>I'm swayed by Andrei A's arguments and proposals on this.

are you talking about this article?

http://www.informit.com/articles/printerfriendly.asp?p=25298

Anuj Goyal wrote:
> I use <rope> very heavily in multithreaded
> environments because there are no copies of the object being passed around, only
> "references to it" (cheaper than copies of the rope).

I've used a reference-counted prefix string trie that does roughly the same thing as rope for years. Not a new idea and doesn't suffer from mad cow disease. I definitely have to add a few more things to the class to make it more thread-safe (or implement r/w locks or ll/sc primitives -- see "Efficient and Practical Constructions of LL/SC variables" by Jayanti, P and Petrovic, S [Dartmouth])

> PS: just for fun.... I was hoping that your next foray would be into the world
> of interpreted languages :) have you heard of APL? J? K?

More generally, you might want to look at John Backus' functional programming work from the late 70s and early 80s. Functional programming seems to be making its way back into the limelight with the DARPA PCA program and multicore processors. The biggest hurdle is I/O: I/O requires state, whereas functional languages don't carry state well.

Let's face it: APL's operators are a bitch to work . It's definitely a neat language for "shape shifting" arrays and vectors, but I have not found a good reason to go back to working in it. You might want to check out PLASM, a functional programming language for graphics, for more ideas.

In article <clomde$2l6m$1@digitaldaemon.com>, Scott Michel says...
>
>Anuj Goyal wrote:
>> I use <rope> very heavily in multithreaded
>> environments because there are no copies of the object being passed around, only
>> "references to it" (cheaper than copies of the rope).
>
>I've used a reference-counted prefix string trie that does roughly the same thing as rope for years. Not a new idea and doesn't suffer from mad cow disease. I definitely have to add a few more things to the class to make it more thread-safe (or implement r/w locks or ll/sc primitives -- see "Efficient and Practical Constructions of LL/SC variables" by Jayanti, P and Petrovic, S [Dartmouth])

and you have to convince the STLport maintainers to add it to STLport :) that will truly be the hard part.  One of the developers I work implemented a ref counted version of "std::string" but he hasn't pushed it on the STLport maintainers because it's a very very hard process to move the STLport people forward.  And it would break some sticky c++ semantics (when you copy std::string, it is _expected_ that a true copy is made, not just a ref count)

>> PS: just for fun.... I was hoping that your next foray would be into the world of interpreted languages :) have you heard of APL? J? K?
>
>More generally, you might want to look at John Backus' functional programming work from the late 70s and early 80s. Functional programming seems to be making its way back into the limelight with the DARPA PCA program and multicore processors. The biggest hurdle is I/O: I/O requires state, whereas functional languages don't carry state well.

>Let's face it: APL's operators are a bitch to work . It's definitely a neat language for "shape shifting" arrays and vectors, but I have not found a good reason to go back to working in it. You might want to check out PLASM, a functional programming language for graphics, for more ideas.

APL operators might painful work with, but try J and K.  They use only ascii characters that are on your keyboard. APL did use a weird char set, but now all the derivatives use ascii.  All 3 of these languages are quite "dense" meaning that every character has a lot of significance.

I have a small web page showing some very very basic examples:

http://goanuj.freeshell.org/k/

my fav is freq of values in a list (sorted):

fq:{g[<g:l[*:'p],'#:'p:=x]}

to the uninitiated it looks like line noise, but to APL, J, K programmers, they can easily figure out what is going on.  Take the same program, write it in c, and you will end up with at least 100 more characters.

I biffed on the last post:

fq:{g[<g:x[*:'p],'#:'p:=x]}   /this is the correct version

only took me 30  seconds to fix :)

"Anuj Goyal" <Anuj_member@pathlink.com> wrote in message news:clmd84$9ah$1@digitaldaemon.com...
>
> >> I don't know if you planned on addressing threading in D, but many
"new"
> >> languages are offering threading as a builtin library.  I don't
recommend
> >going
> >> down that route though :)
> >
> >I'm swayed by Andrei A's arguments and proposals on this.
>
> are you talking about this article?
>
> http://www.informit.com/articles/printerfriendly.asp?p=25298

Actually by his much more recent presentations, etc. He has an article in last summer's CUJ.

Scott Michel wrote:
> I know you're one of the converted. Now for Anuj to discover why it's called 'Linsux'. :-)

Converted???
I never run Linux for more than a couple of hours... Disliked the non-standard extension too much...
Isn't Linux officially a clone???
*BSD is an official Unix AFAIK...

Jan



> 
> 
> -scooter


-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org

I have heard that SuSe is one of the better onces...

Jan



Anuj Goyal wrote:
> hey guys :) i'm not against FreeBSD, I just don't have an extra computer (or
> time) to learn all the system admin tasks of a new OS (though I imagine it can't
> be that much different than any other *nix) another reason is that our customers
> are asking for it and not freebsd. 
> 
> On a semi-related note: we have had a suse box up and running for about 2 months
> now with heavy heavy usage.  We had to poweroff the machine to add a harddrive,
> but other than that it has been running reasonably well.  We have also added a
> bunch of software through yast and haven't run into 'dependency' hell, but I
> remember going through this on other linux boxes that I have tried to set up.
> Hopefully SUSE has done a better job.... we'll see in a coule months :)
> 
> maybe then our corporate customers will ask for freebsd :) 
> 
> I have VMware workstation, so I will try to "install" freebsd onto a virtual
> machine:
> 
> http://www.vmware.com/support/ws45/doc/intro_supguest_ws.html#1032196
> 
> I think that might be a good way to start getting used to it w/o spending extra
> money on hardware :)
> 
> 


-- 
ManiaC++
Jan Knepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org

Suse is what I run at work.  I am thinking about putting freebsd on another box to try it out - I tried it a few years ago and liked it.  However, the push towards linux is inevitable, not necessarily because customers are really going to run on linux, but saying we support linux is a "checkbox" when deals are being signed.  If the software is supported on linux, the customer can _sometimes_ negotiate a better deal with the hardware vendors (HP, AIX, SUN). However, if our software is only supported on AIX, for instance, the customer loses this leverage.

Linux is great for webservers, email servers, dns servers.  It lacks some of the nice 99.999% features of big unixes - hot swapping, guaranteed uptime (backed by $$$), etc.  That being said, the kernel engineers and 3rd party vendors (suse, redhat, mandrake) are working very hard to put these features into the kernel.


>I have heard that SuSe is one of the better onces...
>Jan

In article <clbdot$ep0$1@digitaldaemon.com>, Scott Michel says...
>AT&T tried to write a C++-based Unix kernel back in the early 90s, and failed miserably.

Ten years ago there simply were no properly working C++ compilers. Hell, even now there are unresolved issues within the language.

> So, no, I don't expect I'd ever see a kernel written
>in C++. I'd be surprised if someone managed to do it.

Surprise: http://l4ka.org/projects/pistachio/
There is at least one more microkernel out there that is written in C++ (plus
the obvious inline assembly) but I'm too lazy to google. There is a patch that
enables the Linux kernel to be compiled in C++, including the use of RTTI and
exceptions.

Uli

Ulrich Eckhardt wrote:
>>So, no, I don't expect I'd ever see a kernel written in C++. I'd be surprised if someone managed to do it.
> 
> 
> Surprise: http://l4ka.org/projects/pistachio/
> There is at least one more microkernel out there that is written in C++ (plus
> the obvious inline assembly) but I'm too lazy to google. There is a patch that
> enables the Linux kernel to be compiled in C++, including the use of RTTI and
> exceptions.

Ok, I'm surprised. Looks like Liedtke's work moves forward (in his memory.) I've seen the recent patches to Linux to support C++ in the kernel; it was on /. a few weeks back.


-scooter