Not per se but I would never try to make life easier for someone who is
afraid to let go of the teat for no other reason than that it's comfortable
sucking at it.
On Thu, Sep 8, 2011 at 5:41 PM, Jakob Eriksson wrote:
>
> On Thu, 8 Sep 2011 16:42:22 +0700, Henrik Sarvell
>
> wrote:
>
> > I'm
On Thu, 8 Sep 2011 16:42:22 +0700, Henrik Sarvell
wrote:
> I'm sorry to have to say this but these people are only "real"
programmers
> if they don't target the MS stack with .NET etc, the whole WAMP, XAMPP
> posse
> are just hobbyists and not a iota of energy should be spent to make
their
I'm sorry to have to say this but these people are only "real" programmers
if they don't target the MS stack with .NET etc, the whole WAMP, XAMPP posse
are just hobbyists and not a iota of energy should be spent to make their
lives easier.
They have to suffer, as much as possible.
On Thu, Sep 8,
If they target .NET I mean, I've heard you can get acceptable results on
that stack so some respect is due to those people.
On Thu, Sep 8, 2011 at 4:42 PM, Henrik Sarvell wrote:
> I'm sorry to have to say this but these people are only "real" programmers
> if they don't target the MS stack with
On Thu, Sep 08, 2011 at 08:30:58AM +0200, Alexander Burger wrote:
>
> Sure, if you consider the sheer number of installations and users.
>
> When talking about "interesting segments", I meant that the major
> battlefields these days are either in the smartphones and tablet area,
> with server (cl
Hi Tomas,
> > When talking about "interesting segments", I meant that the major
> > battlefields these days are either in the smartphones and tablet area,
> > with server (cloud) systems, or - traditionally (also in terms of
> > sheer numbers), but largely unnoticed by the consumer - embedded
> >
Hi Alex,
>> It appears to me that it's significantly more relevant then any bsd
>> or sparc ports.
Funny, yeasterday I hit upon the dietlibc:
Why not port the diet libc to *BSD?
- The BSD people are responsible for three thirds of the broken APIs
that plague Unix today. The rest can
Hi Tomas,
> I don't (unfortunately) agree with the statement:
>
>Windows is obsolete in all interesting segments, remaining only on
>the desktop
>
> It appears to me that it's significantly more relevant then any bsd or
> sparc ports. Well, I kind of agree with the statement only becaus
Hi Alex,
>> The PicoLisp family of processes could easily be achieved under
>> Windows using mmap-ed shared memory, IPC, and spawn()s to get it all
>> started. It is just a different model than the old fork() mechanism
>> of UNIX. It might be worth looking into for PicoLisp as a future
>> enhancem
Hi Alex & Randal,
>> Yes, select() is basically the same as for POSIX, but ONLY for
>> sockets. It won't work on files or the keyboard under MS-Win. There
>> are ways around this, but it usually involves breaking out of select,
>> polling the keyboard, and going back to select. Ugh!
>
> Hmm, anot
cygwin does (or used to) have a fork(2) that is supposed to have copying
semantics like unix. I haven't used it in a long time so I don't know if it
was successfully upgraded along with windows.
On Wed, Sep 7, 2011 at 6:20 AM, Alexander Burger wrote:
> Hi Randall,
>
> > > Indeed, this looks quite
Hi Randall,
> > Indeed, this looks quite similar. The 'select' in "winsock2.h" seems to
> > be modeled closely to the POSIX version.
>
> Yes, select() is basically the same as for POSIX, but ONLY for sockets.
> It won't work on files or the keyboard under MS-Win. There are ways
> around this, but
Hi Doug,
>> Yes. Unfortunately we couldn't solve the problem with fcntl(), even
>> under cygwin (don't know if the situation would be better today).
the posix functions are rather bad on windows. It is better to use the
winapi functions directly.
I have ported iolib for Common Lisp to winapi an
On Wed, Sep 07, 2011 at 07:13:08AM +0200, Alexander Burger wrote:
> Yes. Unfortunately we couldn't solve the problem with fcntl(), even
> under cygwin (don't know if the situation would be better today).
>
> But I'm afraid that there will be many other problems. Especially
> select(), fork() and p
Hi Doug,
> I need to use Windows without cygwin dlls for an application I'm
> working on now. So, I had been using miniPicoLisp in my application,
I understand.
> which compiles ok under mingw. That let me avoid even trying to compile
> regular PicoLisp using mingw, and the porting issues that w
s for error messages in miniPicoLisp, relatively quickly.
Cheers,
Doug
--- On Sun, 9/4/11, Alexander Burger wrote:
> From: Alexander Burger
> Subject: Re: error message line numbers
> To: picolisp@software-lab.de
> Date: Sunday, September 4, 2011, 11:29 PM
> Hi Doug,
>
&
Hi Doug,
> Is there a way I can make (mini)PicoLisp give me line numbers from .l source
> files in error messages? There are lots of gnu and/or linux tools (like vim)
> and IDEs etc., that want error messages in a format similar to what gcc spits
> out, like:
>
> Baz.cpp:321: error: 'foobar'
Hi Alex,
Is there a way I can make (mini)PicoLisp give me line numbers from .l source
files in error messages? There are lots of gnu and/or linux tools (like vim)
and IDEs etc., that want error messages in a format similar to what gcc spits
out, like:
Baz.cpp:321: error: 'foobar' was not decl
18 matches
Mail list logo
