[vwnc] Xtreams?

Hi

I read http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&printTitle=Parsing_Expression_Grammars&entry=3409164946
and I wanted to know more about Xtreams.
Is it developed in Smalltalk too?

Stef
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Yep. Xtreams is available in public store.

stephane ducasse wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michael, have you taken a look at Gilad Bracha's combinatorial parsing work for Newspeak which is available in a Squeak version?  It is far cleaner than the PEG stuff.  You get to write and debug Smalltalk messages that express the grammar directly, e.g. the fragment of your example Lexical syntax
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I've thought about it, but haven't tried it yet. I'm not sold on using
Smalltalk syntax to describe grammars.

The devil is in the details and when you start describing terminals, it
all starts to break down using Smalltalk syntax - a simple statement
bloats out in to large message sends. I'd have to try it in earnest to
decide whether that's okay or not. You also can't use () to group
statements together, as in Smalltalk that's a precedence rule, not a
message send, so you end up either using blocks (which I think is a bad
idea here) or adding in another message send.

If we want to be clear about what we're doing and not pollute the system
with "interesting" versions of #, - using regular Smalltalk objects and
messages is about as simple as it gets:

identifier
    ^And with: identStart with: (identCont min: 0 max: Infinity
positive) with: spacing

This was (roughly) how I built the bootstrapping PEG parser.

(I'm becoming a believer in using the right syntax for the right job)

Cheers,
Michael

Eliot Miranda wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks
Stefan S was telling to us that Xtreams was much faster than the other  
serializations framework SRP, Boss...
Do you know why?
Finally what is the license of this project?

On Jan 12, 2009, at 11:03 PM, Michael Lucas-Smith wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stephane ducasse wrote:
> Thanks
> Stefan S was telling to us that Xtreams was much faster than the other
> serializations framework SRP, Boss...
> Do you know why?
I don't know. But I can tell you that it's designed to optimize traffic
between streams, eg: "writeStream write: readStream" will try to
optimize its chunks and use the available bytes and reuse a byte array
buffer.. basically all the stuff it should do.

I don't think it should be any faster marshaling or unmarshaling objects
than any other framework.
> Finally what is the license of this project?
There's no license on it yet.

It's still very much a work in progress. I've had some success using it
for a few minor projects here and there - this PEG stuff is the first
medium sized job I've used it for. There is some documentation, but not
a whole lot.

Ideally, if the design proves itself, it would be nice to make it
available for cross-smalltalk implementation, but that will be up to
Cincom management. The core terminal streams are separate from the
Xtreams design, so plugging in Squeak sockets or VA sockets or SpSockets
should be a breeze.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

this is what stefan mentioned in the pharo mailing-list
so this is cool.


I have not really used it, but a while ago I compared various
serialization frameworks (BOSS, SRP, SIXX) in VisualWorks,
see http://www.parcplace.net/list/vwnc-archive/0805/msg00186.html

Michael Lucas-Smith then privately asked me to try and run
the code with the then-current version of Xtreams. I had to
(trivially) patch unmarshalling for Sets and then ran some
tests comparing the three binary serializers BOSS, SRP, Xtreams.
The numbers below each block are the results reported by
printing the invocations four times in a row each.


|td|
ObjectMemory garbageCollect.
td := TestData new.
Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesBos ]]
8339 8387 8328 8631

|td|
ObjectMemory garbageCollect.
td := TestData new.
Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesSrp ]]
1969 1995 1953 1958

|td|
ObjectMemory garbageCollect.
td := TestData new.
Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesXtreams ]]
1113 1086 1089 1089

|td dump|
ObjectMemory garbageCollect.
td := TestData new.
dump := TestData new saveToBytesBos.
Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesBos:  
dump ]]
2405 2465 2372 2491

|td dump|
ObjectMemory garbageCollect.
td := TestData new.
dump := TestData new saveToBytesSrp.
Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesSrp:  
dump ]]
2228 2247 2278 2282

|td dump|
ObjectMemory garbageCollect.
td := TestData new.
dump := TestData new saveToBytesXtreams.
Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesXtreams:  
dump ]]
1817 1845 1861 1838

HTH,
s.

____________



On Jan 13, 2009, at 9:26 AM, Michael Lucas-Smith wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

When changing the value of the model of an InputFieldView, it's
editTextCache does not update properly if the contents are the same.
Example:
Model changes from float value 1e-5 to 2e-5, and the view has formatting
0,00.
If you've previously focused the Field, it'd have cached 1e-4, if you
focus it again after model has changed, it'll still show 1e-5, not 2e-5.


Quick fix, which at least works for small float values:

InputFieldView>> updateDisplayContents
    "Make the text that is displayed be the contents of the receiver's
model. We
    have to update the cached text even if we are not open right now, to
follow
    any changes in the model"
    | contents |
    editTextCache
        ifNotNil:
            [editTextCache string = model value asString
                ifFalse: [editTextCache := converter printStringFor:
model value]].
    contents := self getContents asText.
    (displayContents text ~= contents or: [displayContents text runs ~=
contents runs])
        ifTrue:
            [self editText: contents.
            self isOpen ifTrue: [self simpleRedisplay]]
        ifFalse: [self isOpen ifTrue: [self resetController]]
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Eliot Miranda wrote: I mean, for this to work you'd have to have a DNU on your expressions..
foo UHEs on #bar, which you take to mean, add it to an And group. How
far do you want to torture the objects before recognizing that the way
to interpret the string is not as Smalltalk code but as a BNF or PEG syntax?

Does: Temporaries <- "|" Identifier* "|"
Become:
    Temporaries
        ^BAR Identifier star Bar
    Bar
        ^'|' literal

I mean, where do you draw the line? What if I want to describe
"Everything except A-Z" ? ![A-Z] versus ($A to: $Z) not. At some point
you get to the decision.. do I accept the higher level abstraction, or
do I use a lower level abstraction. The same argument can be said for
other things too - like SQL, or C interfaces... do we ask our developers
to re-learn their technology using our
slightly-not-quite-like-the-real-thing Smalltalk variation? .. or do we
just give them the technology they already know.

typedef struct {
    int a;
    int b;
    char *c;
} Thing

versus:

Thing := typedef struct: (
    #a int,
    #b int,
    #c char star
)

They both say the same thing, they're fairly similar in style and
content.. however, one is something that will be universally recognized
by the entire development community (gulp, i'd hope) and the other is a
strange bizarro library to build the same information in a syntax that
Smalltalkers are comfortable with.

And then you add on the next layer of problem - that re-education
problem. You have to document it, provide examples for it, teach it.

These are my personal thoughts and feelings on the subject.. I'm sure
other peoples mileage may vary.. but creating a Smalltalk API set to
side-step another syntax feels to me a lot like re-inventing the wheel -
worse because it's a wheel that only fits in to our kind of car.

May be it's unreasonable for me to expect developers to know multiple
different languages and their syntaxes.. perhaps: except that even if
you ask them not to remember another syntax, you are still asking them
to understand the foreign concepts that you're constructing, so it's not
like they aren't aware of what C is, or SQL is, or BNF is.

Another though; none of our environments currently take an ontology and
offer hints as to how to utilize a foreign concept using the API
provided. That's a mouthful.. let me try again. If you write some SQL
and you write:
select bob from blah grouped by thing

the environment, aware of the database, could -help- you write that
statement. It's very natural to validate a parse tree as you build it
(that's how we do syntax colouring after all).
If on the other hand you write:

self select: #( 'bob' ) from: 'blah' groupedBy: 'thing'

... Currently, I've -never- seen a Smalltalk environment that is
designed to recognize a set of API on a class and start validating the
product of the Smalltalk parser tree... not that it couldn't, it's just
a pretty wild thing to consider doing, yet it's a very natural thing to
consider doing in the parser world. It'd also be a slightly hard thing
to do when you start abstracting your code, using cascades and the like
- since you'd probably have to instantiate the objects that the code is
talking about to see what you can see - and it's never as simple as
instantiating their class and calling the method they're currently
writing either.

Implementing the syntaxes as they were deemed appropriate for another
semantic environment means we end up with native Smalltalk objects to
represent those ideas anyway, so that's a useful fallback position - you
can make the objects with Smalltalk, or you can make the objects using
the syntax that describes them.

At some point, I feel the return we get from replacing "native" syntax
with Smalltalk API is of diminishing returns. I might be wrong.

Cheers,
Michael

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Eliot Miranda wrote:
About a year ago, I played with a PEG parser combinator in Smalltalk for
a little while, experimenting with parsing Ruby. I didn't get extremely
deep, but was fairly pleased with this approach. When a pattern gets too
unreadable, you add a method to make it neater. I ended up with
low-level productions that read like this:

        digit := self charBetween: $0 and: $9.
        lcaseLetter := (self charBetween: $a and: $z) / (self char: $_).
        ucaseLetter := self charBetween: $A and: $Z.
       
The senders of #charBetween:and: are wordier than the ideal, but there
aren't many productions that look like that. The higher-level
productions, which is most of them, are quite clean:

        nameStartChar := lcaseLetter / ucaseLetter.
        nameChar := nameStartChar / digit.
        name := nameStartChar , nameChar star


I don't immediately see how this example works. In what I built you'd
have something like:

        ger := (foo, bar, baz) / (zab, rab, oof).

or if that's not what you mean:

         ger := foo, bar, (baz / zab), rab, oof.

Because it's a parser combinator, () just works the way you want,
because it controls the order of parser combination.

>
>     If we want to be clear about what we're doing and not pollute the
>     system with "interesting" versions of #,
>
>
> I don't think adding , to CombinatorialParser counts as pollution, do
> you?  The system doesn't require #, to be defined elsewhere.

Right. #, #/, etc. are only defined within the parser class hierarchy.

Regards,

-Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc