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 > <g...@integrable-solutions.net> 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, merely a >> > lack of sophistication. >> >> Yeah, there was an earlier assertion by Juanjo: >> # I already mentioned the problem with exporting Autoconf's detection >> of processor, >> # which on some platforms is flawed (intentionally, btw). > > Now, I hope, you don't read this as Juan's intentional reduction of the > autoconf's output, don't you? > > What Juan says, in your quote, is that /Autoconf/ intentionally produces > flawed processor identification information. > >> It has been a long day and a short night, and I'm a bit jet lagged. >> I don't see this discussion getting anywhere, and I don't see any chances >> of progress now when I'm jet lagged than when I was not. I already >> said I was dropping the issue. > > Now, wait, Juan pulled out some code to solve your problem, you cannot > just disappear, the onus is upon you to evaluate his proposal! : -)
In private, I did notify Juanjo of my schedule (and I'm mindful that he has a tight schedule too) a few days ago when he informed me of his own tight schedule. But, we spent more time making no progress than actually doing anything. My stating that I was dropping this issue predated the email I sent today. 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 anybody's time, I hope you understand my hesitation in believing (again) that something really useful might get out of this in reasonable time with nobody feeling unduly maligned >> My naivete has been to think from the outset, when I reported what was >> causing the build failure and made suggestion (that was shut down based on >> completely different interpretation of what I meant) that it was just a >> question >> of explaining and if I tried hard enough it should be resolved. However, >> what >> ensued proved me wrong. and the discussion over the week has significantly >> cut into any appetite I had developed over the last couple of years >> in contributing to make ECL a better alternative to other Lisp systems >> out there. > > Now, it's a hard problem, and you've had phylosophical differences (Juan > appears to value high portability, whereas you seem to need a high > degree of completeness). I think that statement underestimates my appreciation of high portability, and I am not sure I am advocating a high degree of completeness -- I had stated several times that I'm not asking for complete ABI specification and that having tokens like :x86_64 or sparc and 64-bit,etc., was already a progress. > I understand that this might not be the best > moment to discuss this further, in your position, but there is no need > for hard feelings either, really. > >> I certainly was disposed to help implement missing features if the proposal >> was >> deemed of interest (and of course subject to improvements.) We never got to >> that point, I doubt we ever will. > > Juan has just posted code, so it's not that bad. : -) I'll look at it tomorrow after I have some rest. > >> Reading past messages suggests that most ECL users who expressed themselves >> are either against, or don't care, or seem to understand but believe >> it is not an ECL >> problem. > > Thankfully, you don't have to convince the users to implement a > feature. : -) -- Gaby ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
