Le 05/07/2015 12:41, stepharo a écrit :
Check the chapter Anne and JC wrote on pharoinprogress.
We discussed a lot about RB because the unification does not identify
the subtree people think about.
I will let Camille and JC comment on it.
What we saw is that we should try something because they a
Check the chapter Anne and JC wrote on pharoinprogress.
We discussed a lot about RB because the unification does not identify
the subtree people think about.
I will let Camille and JC comment on it.
What we saw is that we should try something because they are too many
edge corner.
Le 5/7/15
Joachim,
Le 2 juil. 2015 9:49 AM, "jtuc...@objektfabrik.de"
a écrit :
>
> The problem with Step 2 is: I am not sure if RewriteRules can work in
code that's not compiled. (Well, I am mostly sure this won't work, just
asking for confirmation) You cannot compile methods with Arrays constructed
with
Le 4 juil. 2015 10:58 PM, "stepharo" a écrit :
>
>
>>> Hi thierry
>>>
>>> mark will arriv at Lille saturday for a month. He is working with
>>> Camille on a new tree pattern matching algorithm
>>
>>
>> A generic algorithm or one tied to the RB AST?
>
> A generic algo.
> We will talk with Camille m
Hi thierry
mark will arriv at Lille saturday for a month. He is working with
Camille on a new tree pattern matching algorithm
A generic algorithm or one tied to the RB AST?
A generic algo.
We will talk with Camille monday
because we lost energy on RB matcher.
What was your analysis?
J
Le 02/07/2015 23:16, stepharo a écrit :
Le 1/7/15 21:10, Thierry Goubier a écrit :
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
Hi Stef,
Le 02/07/2015 23:18, stepharo a écrit :
Hi thierry
mark will arriv at Lille saturday for a month. He is working with
Camille on a new tree pattern matching algorithm
A generic algorithm or one tied to the RB AST?
because we lost energy on RB matcher.
What was your analysis?
Than
Hi thierry
mark will arriv at Lille saturday for a month. He is working with
Camille on a new tree pattern matching algorithm
because we lost energy on RB matcher.
Stef
Le 1/7/15 21:29, Thierry Goubier a écrit :
Le 01/07/2015 21:16, jtuc...@objektfabrik.de a écrit :
You mean RewriteRules? I
Le 1/7/15 21:10, Thierry Goubier a écrit :
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 a
Le 1/7/15 12:35, jtuc...@objektfabrik.de a écrit :
Hi there,
I am on VA Smalltalk
For your next successful project you should jump in Ph :)
and therefor using an older version of NeoCSV
(SvenVanCaekenberghe.14). I found a bug in this old version that is
somewhat special.
It seems N
Hannes Hirzel wrote
> though Amber is said to be Pharo compatible there are some problems which
> I
> have to resolve first.
Pharo is the reference implementation, but is a subset. I guess technically
that's "compatible", but "compatible" is vague enough to be easily
misleading...
-
Cheers,
Hello Joachim
In May I did a port of NeoCSV to Cuis Smalltalk.
I followed a process like this
1. download .mcz in its "original" version and unpack it to have the
st file only. Keep
the Core and the Tests st file in the target repository for reference.
2. Make a copy of the two files
3. Modi
On Thu, Jul 2, 2015 at 3:48 PM, jtuc...@objektfabrik.de
wrote:
> Sven,
>
> you are, of course, right!
> I should have checked in Pharo first. But since my version is old anyways, I
> would have to try with at least two versions in order to make sure if the
> bug is fixed or not. As long as keeping
Sven,
you are, of course, right!
I should have checked in Pharo first. But since my version is old
anyways, I would have to try with at least two versions in order to make
sure if the bug is fixed or not. As long as keeping ports current is a
lot of work due to (increasing) differences between
Le 01/07/2015 21:16, jtuc...@objektfabrik.de a écrit :
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 investmen
But before you ask for help on the Pharo ML you should run the NeoCSV code on
Pharo to validate that your assumption hold there. If not, it is a porting
error/problem.
And unit tests are *VERY IMPORTANT* to maintain our sanity across versions
and/or platforms.
Again, what you report as a poten
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 Th
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
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 j
Joachim,
which results do you get on VA Smalltalk for the tests?
Do they all pass?
--Hannes
On 7/1/15, 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
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
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 P
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
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
Th
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
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 o
26 matches
Mail list logo
