Christophe Rhodes wrote:
> Would it be possible to split this patch up into logical
> self-contained pieces?
Yes, of course!
> I now have a mostly-working windows mingw
> environment, and built sbcl CVS on it today, so potentially I could do
> a very limited amount of merging.
I am happy :)
> However, my access to this
> environment is limited to two hours a week, so I don't have time to
> edit failing patches, or even ones that I don't like; additionally,
> breaking it up into pieces will help us work out if there is something
> systematic about failure to map our dynamic space in the place we want
Ok, I have understood
> Regarding the patch that you sent itself: I'm not happy with the
> pathname stuff. I am happy that someone is looking at it, but I don't
> think you've gone about it the right way, unfortunately. You have
> introduced things like VECTOR->STRING and VECTOR->STRING&FREE which I
> think the alien FFI should be dealing with directly; I'm aware that
> there is probably still a division between the stream and alien/octet
> treatments and definitions of external formats, and I would think that
> fixing will make the rest of your patch much simpler.
Ok, but the majority of my functions depends on this encoding/decoding.
Converting string to UCS-2 allien array and converting data from sap (or
alien array) in UCS-2 encoding to string - only this is necessary for me.
I shall be glad to similar conversion for the any encoding also :)
> I agree, I think, that also pathnames need to be able to handle
> general characters rather than the restrictive base-char that is
> presently implemented, and I think I've even been convinced that a
> dynamic variable *pathname-external-format* is a sensible way to
> implement this: it can default to :utf-8 on darwin, (ansi-cp) on
> windows and some locale-dependent value under the other unixes.
Hmm, I shall make converting base-string to string for pathanmes in the
separate patch. I should limit it only for win32?
And again sap(or alien array)<->string conversion is required
> Thank you for developing your patch, in any case; I'm not comfortable
> with merging it directly, and I don't have the resources to develop
> sensibly on Windows, but I hope that the functionality you've
> developed will make it into SBCL CVS given a little more work.
Patches follow this letter!
Thanks for your nice work!
And excuse me bad english.
WBR, Yaroslav Kavenchuk.