You mean RewriteRules? I was planning to do that, for this exact reason.
But you know how things go when there is a long list of priorities.
I know it saves a lot of time and makes porting so much more safe, but
it needs an up-front investment in time...
Joachim
Am 01.07.15 um 21:10 schrieb Thierry Goubier:
Le 01/07/2015 21:07, jtuc...@objektfabrik.de a écrit :
I gave up on porting tests. VAST doesn't support creating Arrays with
curly braces, and they are used all over the place in Pharo code. I wuld
use them if I had them, so this is not an accuse or anything. It's just
a huge load of work to keep tests up to date when porting newer
versions, so I just ignore tests when porting. A sad truth.
Maybe we should write a refactoring to change those curly braces into
an equivalent Array based syntax?
I'll have some significant porting from Pharo to do one of these days,
so maybe I'll setup something for that.
Thierry
Joachim
Am 01.07.15 um 16:14 schrieb H. Hirzel:
Joachim,
which results do you get on VA Smalltalk for the tests?
Do they all pass?
--Hannes
On 7/1/15, jtuc...@objektfabrik.de <jtuc...@objektfabrik.de> wrote:
I am not complaining. It just makes porting harder.
What made the thing especially strange was that I only had that
problem
with uploaded files because the Browser removes the trailing CrLf (or
better, doesn't add another one in the multipart form data). So
reading
from a file all works like a charm, but not when you process the same,
uploaded file on the server side...
Joachim
Am 01.07.15 um 15:12 schrieb Sven Van Caekenberghe:
Yes, on Pharo, #next (and #peek or #peekFor:) all return nil when
#atEnd.
It is the way it is (I am personally for stricter semantics), but
that
fact is certainly used in code all allround the place.
On 01 Jul 2015, at 15:06, jtuc...@objektfabrik.de wrote:
Hi Sven,
I didn't test on Pharo. But I remember seeing differences in the way
Pharo and VAST react to reads beyond the end of a Stream.
Not sure, but this could have been in NeoCSV context two or three
years
ago.
So it is very likely I was bitten by platform differences.
Thanks for answering.
Joachim
Am 01.07.15 um 14:05 schrieb Sven Van Caekenberghe:
Hi Joachim,
First, thanks for the feedback.
Second, since you are on a different platform, that might be a
factor.
Did you test your problem on Pharo itself ?
Because there are already unit tests specifically for the case you
describe:
#testEmptyLastFieldUnquoted
#testEmptyLastFieldQuoted
These obviously pass for Pharo, do they pass for you ?
Maybe your problem case is slightly different though ?
Sven
On 01 Jul 2015, at 13:40, jtuc...@objektfabrik.de wrote:
Hi,
I've tried porting SvenVanCaekenberghe.20 and see the same
problems in
this version. IN addition to the fix already mentioned, I also
had to
change readSeparator:
readSeparator
^self atEnd ifFalse: [self peekFor: separator]
As far as I can tell by now, this fixes the problem at hand. Any
ideas
if this is a safe fix?
Joachim
Am 01.07.15 um 12:35 schrieb jtuc...@objektfabrik.de:
Hi there,
I am on VA Smalltalk and therefor using an older version of
NeoCSV
(SvenVanCaekenberghe.14). I found a bug in this old version
that is
somewhat special.
It seems NeoCSV cannot handle the situation where the very last
field
is just empty AND if there is no trailing CRLF at the end of the
file.
Somethinng like this:
SecondLastColumnValue;;<EOF>
In that case, readField fails because it tries to do a
readQuotedField
or readUnquotedField, both of which try to read beyond EOF.
So I changed readField to this:
readField
^self atEnd "In case the very last field of a file is
empty, like
'45;56;;'"
ifTrue: ['']
ifFalse: [self peekQuote ifTrue: [self readQuotedField]
ifFalse: [self readUnquotedField]]
and all seems fine so far.
Side note: My original file has a trailing CrLf but if I upload
it via
a browser to a Seaside Server, the Browser cuts off the trailing
CrLf
(I can see this in the Browser's Network debugging tools - both
in IE
and FF) - so it seems NeoCSV has to be ready for this situation.
Joachim
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg
http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg
http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
