On Wed, 5 Jan 2011 02:46:07 -0500
Matthew Mondor wrote:
> Oh, of course it could be renamed to split-sequence or the like too,
> with instances of string replaced with sequence...
Cleaned up implementation attached, if it may serve (license as MIT/BSD
or LGPL as wanted)
--
Matt
(defun white-sp
On Wed, 5 Jan 2011 02:46:07 -0500, Matthew Mondor
wrote:
> On Wed, 5 Jan 2011 02:36:10 -0500
> Matthew Mondor wrote:
>
> > I also have an alternative implementation I previously wrote, which you
> > can license and use as needed if you happen to prefer it, but in my
> > case I made it return an
On Wed, 5 Jan 2011 02:36:10 -0500
Matthew Mondor wrote:
> I also have an alternative implementation I previously wrote, which you
> can license and use as needed if you happen to prefer it, but in my
> case I made it return an array rather than a list (attached).
Oh, of course it could be rename
Just a note: the split-words implementation appears to miss the last
word of the line.
I also have an alternative implementation I previously wrote, which you
can license and use as needed if you happen to prefer it, but in my
case I made it return an array rather than a list (attached).
Thanks,
On 4 January 2011 16:41, Gabriel Dos Reis wrote:
> On Tue, Jan 4, 2011 at 8:17 AM, Samium Gromoff
> <_deepf...@feelingofgreen.ru> wrote:
[...]
>> Juan has just posted code, so it's not that bad. : -)
>
> I'll look at it tomorrow after I have some rest.
I've given Juan's script a try on a Mac Pro
On Tue, 4 Jan 2011 08:41:52 -0600
Gabriel Dos Reis wrote:
> I just landed in Paris and see that a preliminary patch has been proposed
> when a lot of heat has already spilled into hard feelings on both sides.
> Given what it took to get here, and considering that I had no intention to
> waste
>
On Tue, Jan 4, 2011 at 8:17 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> On Tue, 4 Jan 2011 05:10:55 -0600, Gabriel Dos Reis
> wrote:
>> On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff
>> <_deepf...@feelingofgreen.ru> wrote:
>> > My impression was that ECL doesn't /add/ information
On Tue, 4 Jan 2011 05:10:55 -0600, Gabriel Dos Reis
wrote:
> On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff <_deepf...@feelingofgreen.ru>
> wrote:
> > My impression was that ECL doesn't /add/ information anywhere -- it merely
> > /forwards/ whatever is fed to it by autoconf. It's not intent, m
On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> I am replying to several mails, by different authors here, sorry for
> that.
>
> On Sat, 01 Jan 2011 13:13:36 -0600, Gabriel Dos Reis wrote:
>> At the moment, since the discussion is stall and it does not appear
On Mon, Jan 3, 2011 at 5:13 PM, Samium Gromoff
<_deepf...@feelingofgreen.ru>wrote:
> My impression was that ECL doesn't /add/ information anywhere -- it merely
> /forwards/ whatever is fed to it by autoconf. It's not intent, merely a
> lack of sophistication. Juan, am I right? [...]
> In other wo
> From: Samium Gromoff [mailto:_deepf...@feelingofgreen.ru]
> elsewhere, Juan-Jose Garcia Ripoll wrote:
> > * You, Gabriel, insist on the need to provide information
> to users, but give
> > no precise names nor do you explain how I should offer this
> > information.
>
> Well, he does, with a /
I am replying to several mails, by different authors here, sorry for
that.
On Sat, 01 Jan 2011 13:13:36 -0600, Gabriel Dos Reis wrote:
> At the moment, since the discussion is stall and it does not appear that
> ECL is willing to make itself more useful (at least as far as OpenAxiom
> is concerne
On Sun, 02 Jan 2011 21:09:29 +0300
Samium Gromoff <_deepf...@feelingofgreen.ru> wrote:
> The solution is simple: let the OpenAxiom authors, as seemingly the most
> picky about these arch/cpu/binary flags, take over maintenance of
> TRIVIAL-FEATURES, and depend OpenAxion upon it.
I think that's a
On Sun, 2 Jan 2011 23:53:39 +0100
Juan Jose Garcia-Ripoll wrote:
> I started precisely the ECL project because I was not able to build some
> software on my system and I was not clever enough to fill a configuration
> file, and much less learn the innards of the OS I was using. I shied away
> alw
On Sun, Jan 2, 2011 at 4:53 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis
> wrote:
>>
>> Because of ECL's design decision to target the C programming language,
>> and the C programming language has lots ot parameters left to the
>> implementation, it is cer
On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
> On Sun, Jan 2, 2011 at 4:55 PM, Juan Jose Garcia-Ripoll
> I was making a point to someone claiming that "ECL just works."
> You don't have to feel bad about it or feel that it is a flame war.
> It was meant to. It was simply pointing out a basic fac
On Sun, Jan 2, 2011 at 4:55 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 11:25 PM, Gabriel Dos Reis
> wrote:
>>
>> However, we are all happy because for the limited set of platforms that
>> ECL *actually* runs, we can expect most C compilers to be blindsighted
>> and generate codes
On Sun, Jan 2, 2011 at 11:25 PM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> However, we are all happy because for the limited set of platforms that
> ECL *actually* runs, we can expect most C compilers to be blindsighted
> and generate codes that *appear* to work -- even if the sou
On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> Because of ECL's design decision to target the C programming language,
> and the C programming language has lots ot parameters left to the
> implementation, i*t is certainly ECL's responsability to document
On Sun, Jan 2, 2011 at 4:06 PM, David Brown wrote:
> Then, what exactly, are you asking for? There are an unbounded number
> of combinations that ECL can support,
"can support" is very different from "actually support". For example, using
your criteria, there is an unbounded set of standard C
On Sun, Jan 2, 2011 at 4:04 PM, David Brown wrote:
> On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
>
>> On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
>>
>>> Most Lisp compilers take significant amounts of work to make them build
>>> on a different configuration. ECL often just works. Asking
On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
> On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
>> On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
>>
>>> On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
>>
>>> Of course, the number of combinations will be always limited, in practice.
>>> I
On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
> On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
>
>> Most Lisp compilers take significant amounts of work to make them build
>> on a different configuration. ECL often just works. Asking it to try
>> and deduce a bunch of information about that
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
> Most Lisp compilers take significant amounts of work to make them build
> on a different configuration. ECL often just works. Asking it to try
> and deduce a bunch of information about that configuration would make it
> much less portable tha
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote:
> On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
>
>> On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
>
>> Of course, the number of combinations will be always limited, in practice.
>> I never asked for an unlimited combinations.
>
> It see
On Sun, Jan 02 2011, Gabriel Dos Reis wrote:
> On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
> Of course, the number of combinations will be always limited, in practice.
> I never asked for an unlimited combinations.
It seems to me that you have. Because it targets C, ECL is very eas
On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis
> wrote:
>>
>> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
>> wrote:
>>
>> > This seems to be the current attitude in the Autoconf'ed world, where
>> > uniform build en
On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
> wrote:
>
> > This seems to be the current attitude in the Autoconf'ed world, where
> > uniform build environments are assumed and deviations from t
On Sat, 1 Jan 2011 15:30:18 +0100, Juan Jose Garcia-Ripoll
wrote:
> What I meant is the following: ECL does not gather specific information
> about processor types and how they are used. Instead there are checks for C
> types, sizes and precisions , some of which are performed during the
> "autoc
On Sun, Jan 2, 2011 at 10:58 AM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 10:39 AM, Gabriel Dos Reis
> wrote:
>>
>> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
>> wrote:
>> > On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis
>> > wrote:
>> >>
>> >> > Extracting the in
On Sun, Jan 2, 2011 at 10:39 AM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
> wrote:
> > On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis
> > wrote:
> >>
> >> > Extracting the information from there might be easier and more
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> This seems to be the current attitude in the Autoconf'ed world, where
> uniform build environments are assumed and deviations from them are a
> responsibility of the packager or builder.
I don't know what you mean by that. I don't
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> * Autoconf triplets. ECL currently exports them as *features* and as the
> output of other functions but they do not work. They are unreliable and OS
> X, where OpenAxiom failed to build because of this, is an example.
Autoconf rep
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> Now let's put this in context. Should OpenAxiom or any other ECL user want
> to link against a preinstalled GMP, or gnome library, would they demand that
> the library supplies this information? How would they obtain that
> informat
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
wrote:
> On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis
> wrote:
>>
>> > Extracting the information from there might be easier and more portable.
>>
>> Yes, that is what I suggested in private conversion. In fact, all it
>> takes is
>> j
On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> > Extracting the information from there might be easier and more portable.
>
> Yes, that is what I suggested in private conversion. In fact, all it takes
> is
> just link a dummy C file against the GMP lib
On Sat, Jan 01 2011, Gabriel Dos Reis wrote:
> On POSIX systems, ECL can just issue `file
> test-program-linked-against-required-c-lib' and use the output to
> determine the binary flavour. On non-posix systems (not many, among
> the platforms where this actually matters.), it can have its own
>
On Sat, Jan 1, 2011 at 3:51 PM, David Brown wrote:
> On Sat, Jan 01 2011, Gabriel Dos Reis wrote:
>
>> On POSIX systems, ECL can just issue `file
>> test-program-linked-against-required-c-lib' and use the output to
>> determine the binary flavour. On non-posix systems (not many, among
>> the plat
On Sat, Jan 1, 2011 at 2:41 PM, DS wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> What happens on macintel 64-bit with ECL is that ECL
>
>> puts out I686 instead there -- even when it is clearly a 64-bit binary
>
>> program.
>
>> ...
>
>> I explained that to Juanjo and suggested
On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
> What happens on macintel 64-bit with ECL is that ECL
> puts out I686 instead there -- even when it is clearly a 64-bit binary
> program.
> ...
> I explained that to Juanjo and suggested that ECL puts a more correct
> token on *FEATURES*.
On Sat, Jan 1, 2011 at 2:23 PM, DS wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> Anyway, I do no believe that the suggestion for ECL to make available
>
>> its binary flavor is equivalent to building and maintaining a database
>
>> of all imaginable ABIs and all combinations of
On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
> Anyway, I do no believe that the suggestion for ECL to make available
> its binary flavor is equivalent to building and maintaining a database
> of all imaginable ABIs and all combinations of processors.
I believe Juanjo was referring to t
What I meant is the following: ECL does not gather specific information
about processor types and how they are used. Instead there are checks for C
types, sizes and precisions , some of which are performed during the
"autoconf" phase, some others when ECL is compiled. This information is
available
On Thu, Dec 30, 2010 at 9:14 PM, DS wrote:
> Why not check what information is put in *features* by other
> implementations? If OpenAxiom runs on them, then that should be enough.
>
> Keywords like :X86 and :X86-64 seem common, and this should be easy to
> figure out when building ECL. :ILP32 o
Why not check what information is put in *features* by other
implementations? If OpenAxiom runs on them, then that should be enough.
Keywords like :X86 and :X86-64 seem common, and this should be easy to
figure out when building ECL. :ILP32 or :LP64 might be even more
informative than that
On Thu, 30 Dec 2010 10:42:43 +0100
Juan Jose Garcia-Ripoll wrote:
Sorry that I didn't read the previous discussions, which most probably
happened on another list (and it's unclear to me why OpenAxiom requires
that implementation-dependent low-level information; why it cannot use
an FFI library or
I have no preconceived idea about your problem, however, I will note
that:
Juan Jose Garcia-Ripoll
writes:
> Since ECL does not really care about the processor type, it is fine
> with it, and just works: it only relies on information provided by the
> compiler, such as type sizes, alignments, a
47 matches
Mail list logo
