smee-development — Smee Developers

[Smee-development] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Smee-development] RE: regex and Smee

[Pennell, D. <DPe...@qu...>]

Vassili,

Thanks for the upadate.  I'm going to follow your recommendation and start
with option 4.  By the time I get done with that your December meeting
should have transpired.

If the new version of Regex does end up as a Cincom product, will it still
be available for porting to other platforms?

-david

> -----Original Message-----
> From: Vassili Bykov [mailto:va...@pa...] 
> Sent: Thursday, November 20, 2003 2:47 AM
> To: Pennell, David
> Subject: RE: regex and Smee
> 
> Hello David,
> 
>  > > Here are the differences I noticed:
> > > >
> > > >          QuantifierPrefix ::
> > > >                  *
> > > >                  +
> > > >                  ?
> > > >                  { DecimalDigits }
> > > >                  { DecimalDigits , }
> > > >                  { DecimalDigits , DecimalDigits }
> > > >
> > > > The {...} construct is not supported by Regex (this is probably 
> > > > the worst problem with it).
> > >
> > > I'm not following you here.  What do you mean by "the (...) 
> > > construct"?
> 
> It's the "{...} construct" (curly braces). Something like 
> "a{3,5}" is supposed to match between 3 and 5 occurrences of 
> a, and Regex does not understand that.
> 
>  > I remember you mentioning a new version when we talked at StS.
>  > What is the new version about?
>  > What is the status?
>  > Are you interested in adding ECMAScript support or 
> providing  > a mechansim that would allow me to?
> 
> The new version is a nearly complete rewrite of the whole 
> thing. It does everything Python regular expressions do, so I 
> expect it is a superset of what is required for ECMAScript. 
> The status is the dreaded "90% complete". 
> I have the basic matcher working and functionally complete 
> (and 170+ tests to prove it). However, the optimizations I 
> wanted to get done to improve matching speed are not 
> done--and one of the reasons I rewrote so much of it was to 
> allow those optimizations. I haven't worked on it for a 
> while, and not sure when I would be able to get back to it. I 
> need either a happy coincidence of being in the mood to write 
> some code when there is a long holiday, or Regex being made 
> an official product. On our planning meeting next month we 
> are going to consider that, so if it happens I might get some 
> time to work on it "officially". This is pretty much all I 
> can say at the moment.
> 
>  > It looks like I have the following choices:
> > > 1 roll my own ECMAScript compatible regex engine
> > > 2 try to map ECMAScript semantics to Regex11 semantics (I 
> don't even 
> > > know if this is doable)
> > > 3 wait for the new version of your code (assuming that it 
> will be or 
> > > can be made to be ECMAScript compliant)
> > > 4 cut a first release with the current Regex code, document the 
> > > differences and then go to 1,2 or 3.
> > >
> > > What do you recommend?
> 
> I wish I could suggest (3), but before the meeting in 
> December I don't want to give empty promises. How about (4) 
> to begin with, and we'll choose between 1, 2 and 3 once the 
> "official" Regex status is clear?
> 
>  > A couple of other questions:
> > > - Doesn't your ":characterMethod:" syntax conflict?
> 
> Yes, it does. In the new version I keep this option (and even 
> extend it to allow inlined Smalltalk blocks), but it is 
> accessible using the syntax used for syntax extensions in 
> Python regex (":isDigit:" becomes "(?#isDigit)"), so there is 
> no problem with that.
> 
> > > - Do you support 16bit characters?
> 
> Good question. I never checked. I don't think I do any 
> dispatch on character codes anywhere, or anything like that, 
> so I expect that they either work, or would work after a bit 
> of tweaking.
> 
>  > Do you mind if I copy this thread to the Smee list - that way
> > > it gets archived.
> 
> By all means!
> 
> Cheers,
> 
> --Vassili
> 
> 
> > >
> 
> --
> Vassili Bykov [|] <va...@pa...> VisualWorks 
> Engineering, Tools Project
> 

[Smee-development] Smee Status and next steps

[Pennell, D. <DPe...@qu...>]

Current status:
Parsing
=======
- All syntax should be accepted except RegExp literals and Unicode source.
- Error reporting is dismal - most errors end up as "Unexpected token", some
as infinite loops in parser

Core Engine
==========================
- All expressions (except those involving RegExp literals) are implemented
and have test cases.
- Number to string conversion is imcomplete - I need to tackle the "Gay
algorithm".
  The biggest issue is that doubles are going to print with "d" at the end.
- Runtime error reporting could certainly be improved.  The spec generally
just says "throw XXXError", I've begun using
  Mozilla as a reference for adding a reasonable message to XXXError.
- Runtime environment is now "thread-safe".  All execution state is in the
execution context.

Objects
=======
- Global
  All except parseInt(), parseFloat(), decodeURI(), decodeURIComponent(),
encodeURI(), encodeURIComponent()
- Function
  Enough exists to support builtin functions and user defined function, none
of the Function.prototype functions
  except toString() are implemented yet.
  Additional property:  setting trace to true (or anything that will convert
to true) will generate SmeeFunctionEnter
  and SmeeFunctionExit exceptions. The exceptions carry the name of the
function, the arguments and on exit, the
  return value.
- Array
  Functionally complete, but it deserves some performance improvement.
- String
  All functions complete except those that take RegExp objects as arguments:
match(), replace(), search(), split().
  Several functions need additional Unicode support: localeCompare(),
toLowerCase(), toLocaleLowerCase(), 
  toUpperCase(), toLocaleUpperCase()
- Boolean
  Complete
- Number
  All functions except those that convert to strings (that pesky Gay
algorithm again):  toFixed(),toExponential(),
  toPrecision()
  Additonal functions:  toInt32(), toUint16() and toUint32().
- Math
  All functions except atan2() and pow()
- Date
  Locale specific functions are identical to the non-locale versions.
  Specification allows implementation choice on string representation, both
for Date->string and string->Date.
  Smee uses a simple yyyy.mm.dd-hh:mm:ss.mmm format.
- RegExp
  The object exists and could be constructed, but none of the functions are
implemented.
  Vassili Bykov provided a summary of the differences between his Regex11
and the ECMAScript spec.  There are quite
  a few issues, many of which are resolved in his next version.  I'm trying
to decide if I should wait for his next
  version or just build my own from the ECMAScript spec.  I may just provide
a first cut that uses Vassili's code and
  then decide.
- Error (and its children)
  Complete.

Next Steps
==========
- Finish string->number, Global and Math
- SmeeHostObject will wrap any non-Smee object.  You will have a choice of
instantiating this in promiscuous mode
  or of explicitly specifying which bits of the protocol are exposed.  In
promiscuous mode accessor methods will 
  appear as value properties and all other methods will appear as function
properties.  The host objects class will
  appear as the prototype.  New properties will be added to the wrapper.  I
haven't enough time thinking about
  the controlled access instantiation protocol yet.  It seems clear that you
will want to provide a collection of
  methods that are accessible, but I'm not sure what else is needed.
- Move prototype functions from class side to instance side
  It seemed like the right choice at the time, but now that I have a better
understanding of prototype functions,
  "this" and function tranferrance, I realize that I can move these to the
instance side and simplify things.
- Implement RegExp.  I'll probably do this in two phases - use Regex11 in
the first phase, and either use its
  successor in the second phase or roll my own.  The first phase would also
involve completing the String prototype
  functions.
- Improve error handling in parser
- Improve error reporting in parser and runtime
- Add Unicode support
- Performance.  Improve performance when and if necessary.  I've run one
test so far:
  Parse 'a+b*2'.  Instantiate global context.  In loop, set values for a and
b in context, execute program and retrieve
  result.  On my 1GHz notebook, it executes at 30 KHz.  I need to run tests
with function calls, I expect that they
  need some work.

RE: [Smee-development] Smee 1.30

[Pennell, D. <DPe...@qu...>]

Michael Lucas-Smith wrote:

> Congradulations on the 1.30 release of Smee David. It looks 
> like you've come a long way with it in a very short period of 
> time. I look forward to seeing what you can do with the DOM support :)

Thanks!  Its been fun busting away on this, but I'm a little knackered and
I'm going to take a 3-day weekend and then hit it hard again.

I've plugged Smee into one of our products here at work and early feedback
has been very positive.  When it comes to the extension language, the
documentation simply describes the host objects (there is only one in
addition to the in-built ECMAScript objects) and says that it is standard
ECMAScript/JavaScript.  I gave a preview copy to a consultant in France and
he came back with a completed application with no questions asked.  Previous
experience with a Smalltalk based extension language and lots of
documentation explaining it was very different.  A curious side-effect has
been a tendency to want to solve every problem by allowing configuration
options to be scripts.  We are trying to find a way to strike a balance
here.

-david

[Smee-development] Smee 1.30

[Michael Lucas-S. <mic...@sp...>]

Congradulations on the 1.30 release of Smee David. It looks like
you've come a long way with it in a very short period of time. I look
forward to seeing what you can do with the DOM support :)

-- 
Best regards,
 Michael                          mailto:mic...@sp...

RE: Re[2]: [Smee-development] Thoughts on example for host integr ation

[Pennell, D. <DPe...@qu...>]

> I think there are two things you're suggesting here. You're suggesting 
> that XSL be extended to have a JS mode, where the output of the 
> function is the result of executing the JS?
> 
> Then it also sounds like you want a way to define a template match 
> using JS. I don't think this is a good idea. If you support the 
> function idea then you can embed functions in a template match any 
> way.
> 
> Adding a function to XSL to evaluate JS should be quite easy to do.
> I've added a couple myself already now.

OK, I'll wait until somebody asks before jumping on this one.

-david

Re[2]: [Smee-development] Thoughts on example for host integration

[Michael Lucas-S. <mic...@so...>]

>> There are so many ways to do this? What did you have in mind? 
>> (ie: what did you mean by 'both modes')

PD> Disclaimer - its been a while since I looked at XSLT, quite a while.

PD> IIRC, XSLT supports a mode where your template drives the transformation and
PD> you "pull" from the source DOM and another mode where you navigate the
PD> source DOM and explicitly construct the output DOM.

PD> In the first mode, it would be handy to be able to use JS to:
PD> - map input tags/values to output tags/values
PD> - conditionally create output leaves of the output

I think there are two things you're suggesting here. You're suggesting
that XSL be extended to have a JS mode, where the output of the
function is the result of executing the JS?

Then it also sounds like you want a way to define a template match
using JS. I don't think this is a good idea. If you support the
function idea then you can embed functions in a template match any
way.

Adding a function to XSL to evaluate JS should be quite easy to do.
I've added a couple myself already now.

PD> In the second mode, being able to use JS seems even more compelling - its is
PD> procedural by nature and the JS interface to the XML DOM should be pretty
PD> expressive and terse.

PD> BTW - my first project at work that's using Smee uses an approach very
PD> similar to the first mode.  The input is one or more streams of
PD> records/fields and the output is a domain specific object tree.  You define
PD> the input schema(s) and define a template for the output.  You use JS to
PD> define filters, conditional object creation and object attribute
PD> expressions.  As each new record arrives, it fires the template with a
PD> record in the form of a JS object.


PD> -------------------------------------------------------
PD> This SF.net email is sponsored by: SF.net Giveback Program.
PD> SourceForge.net hosts over 70,000 Open Source Projects.
PD> See the people who have HELPED US provide better services:
PD> Click here: http://sourceforge.net/supporters.php
PD> _______________________________________________
PD> Smee-development mailing list
PD> Sme...@li...
PD> https://lists.sourceforge.net/lists/listinfo/smee-development


-- 
Michael
http://www.softwarewithstyle.com
mic...@so...

RE: [Smee-development] Thoughts on example for host integration

[Pennell, D. <DPe...@qu...>]

> There are so many ways to do this? What did you have in mind? 
> (ie: what did you mean by 'both modes')

Disclaimer - its been a while since I looked at XSLT, quite a while.

IIRC, XSLT supports a mode where your template drives the transformation and
you "pull" from the source DOM and another mode where you navigate the
source DOM and explicitly construct the output DOM.

In the first mode, it would be handy to be able to use JS to:
- map input tags/values to output tags/values
- conditionally create output leaves of the output

In the second mode, being able to use JS seems even more compelling - its is
procedural by nature and the JS interface to the XML DOM should be pretty
expressive and terse.

BTW - my first project at work that's using Smee uses an approach very
similar to the first mode.  The input is one or more streams of
records/fields and the output is a domain specific object tree.  You define
the input schema(s) and define a template for the output.  You use JS to
define filters, conditional object creation and object attribute
expressions.  As each new record arrives, it fires the template with a
record in the form of a JS object.

RE: [Smee-development] Thoughts on example for host integration

[Pennell, D. <DPe...@qu...>]

Repost of Michael Lucas-Smith reply to David Pennell:

DP>> I think that HostObjectWrapper can be implemented as described (I 
DP>> believe the Rhino guys did the same thing for Java).  This is going 
DP>> to be appropriate for an audience that you want to give that kind 
DP>> of power.  I also want to support a wrapper style that lets you 
DP>> have fine-grained control over the permeability between ST and JS.  
DP>> You might want that control because of security concerns or because 
DP>> of support concerns - you just might not want users to have access 
DP>> to ALL
DP> objects in your image.

I agree entirely.

DP>> I'm going to need to put together an example of integrating Smee 
DP>> with a host application.  I'm thinking that with:Style: would make 
DP>> a nice example.  What do you think?

I think that's a fantastic idea. Once I've stabalised the dynamic updates
and a parcel building problem we have I'll start sending you advanced copies
of Tech Preview 2 for you to play with.

Tech Preview 2 already includes the ability to use JavaScript, but because
of the lack of DOM and host objects in the version I used, it is not
terribly useful :)

It should be immediately obvious the kinds of support that should be added,
not just to support web-js code, but also to support the sorts of operations
smalltalkers might want to use.

It would be possible to build a development environment for javascript and
XML using with:Style. We could clash heads on this after all the core work
is done if you like?

DP>> Other semi-random thoughts:
DP>> - A JS XPath object would make a nice companion to the native 
DP>> RegExp
DP> object.

Yep. I'd like to expose XPath's in to the DOM tree of VW's XML objects more,
they're underutilitised so far.

DP>> - JS in XSLT might be interesting - in both modes

There are so many ways to do this? What did you have in mind? (ie: what did
you mean by 'both modes')

FW: [Smee-development] Thoughts on example for host integration

[Pennell, D. <DPe...@qu...>]

This is a re-posting of a message from Michael-Lucas Smith to David Pennell:


MLS> The more I've been thinking about your Smee, the more I've been 
MLS> coming to the conclusion that this is the exact thing required to 
MLS> break a Smalltalk application environment out of the Smalltalk 
MLS> community. I could package up with:Style and market it to 
MLS> non-Smalltalkers as a Javascript development environment, with DOM 
MLS> inspectors, obviously an XML renderer and one day may be a debugger 
MLS> of sorts.

DP> I knew it seemed like a good idea when I started, but the more I 
DP> think about it, the more convinced I am.  I finished that internal 
DP> paper and ended up building examples of old language to new language 
DP> for all 7(gulp) of our little languages and they all looked more 
DP> intuitive to the average Joe (at least that is early feedback - 
DP> first
formal review on Thursday).
 
MLS> It gives the curly brace crowd something to 'hold on to' when trying 
MLS> out the software. You may have struck a real chord here David. Is the 
MLS> idea to have HostObjectWrapper so that the Javascript can manipulate 
MLS> any object in the system if it can get a hold of it? If so, then JS 
MLS> is a valid alternative to St in an St VM.

DP> I think that HostObjectWrapper can be implemented as described (I 
DP> believe the Rhino guys did the same thing for Java).  This is going 
DP> to be appropriate for an audience that you want to give that kind of 
DP> power.  I also want to support a wrapper style that lets you have 
DP> fine-grained control over the permeability between ST and JS.  You 
DP> might want that control because of security concerns or because of 
DP> support concerns - you just might not want users to have access to 
DP> ALL
objects in your image.

DP> I'm going to need to put together an example of integrating Smee 
DP> with a host application.  I'm thinking that with:Style: would make a 
DP> nice example.  What do you think?

DP> Other semi-random thoughts:
DP> - A JS XPath object would make a nice companion to the native RegExp
object.
DP> - JS in XSLT might be interesting - in both modes

Re: [Smee-development] Thoughts on example for host integration

[Michael Lucas-S. <mic...@sp...>]

DP>> I think that HostObjectWrapper can be implemented as described (I
DP>> believe the Rhino guys did the same thing for Java).  This is going
DP>> to be appropriate for an audience that you want to give that kind of
DP>> power.  I also want to support a wrapper style that lets you have
DP>> fine-grained control over the permeability between ST and JS.  You
DP>> might want that control because of security concerns or because of
DP>> support concerns - you just might not want users to have access to ALL
DP> objects in your image.

I agree entirely.

DP>> I'm going to need to put together an example of integrating Smee 
DP>> with a host application.  I'm thinking that with:Style: would make a
DP>> nice example.  What do you think?

I think that's a fantastic idea. Once I've stabalised the dynamic
updates and a parcel building problem we have I'll start sending you
advanced copies of Tech Preview 2 for you to play with.

Tech Preview 2 already includes the ability to use JavaScript, but
because of the lack of DOM and host objects in the version I used, it
is not terribly useful :)

It should be immediately obvious the kinds of support that should
be added, not just to support web-js code, but also to support the
sorts of operations smalltalkers might want to use.

It would be possible to build a development environment for javascript
and XML using with:Style. We could clash heads on this after all the
core work is done if you like?

DP>> Other semi-random thoughts:
DP>> - A JS XPath object would make a nice companion to the native RegExp
DP> object.

Yep. I'd like to expose XPath's in to the DOM tree of VW's XML objects
more, they're underutilitised so far.

DP>> - JS in XSLT might be interesting - in both modes

There are so many ways to do this? What did you have in mind? (ie: what
did you mean by 'both modes')



DP> -------------------------------------------------------
DP> This SF.net email is sponsored by: SF.net Giveback Program.
DP> SourceForge.net hosts over 70,000 Open Source Projects.
DP> See the people who have HELPED US provide better services:
DP> Click here: http://sourceforge.net/supporters.php
DP> _______________________________________________
DP> Smee-development mailing list
DP> Sme...@li...
DP> https://lists.sourceforge.net/lists/listinfo/smee-development



-- 
Best regards,
 Michael                            mailto:mic...@sp...

[Smee-development] Thoughts on example for host integration

[David P. <dpe...@qu...>]

>> The more I've been thinking about your Smee, the more I've been 
>> coming to the conclusion that this is the exact thing required to 
>> break a Smalltalk application environment out of the Smalltalk 
>> community. I could package up with:Style and market it to 
>> non-Smalltalkers as a Javascript development environment, with DOM 
>> inspectors, obviously an XML renderer and one day may be a debugger 
>> of sorts.

DP> I knew it seemed like a good idea when I started, but the more I 
DP> think about it, the more convinced I am.  I finished that internal 
DP> paper and ended up building examples of old language to new language 
DP> for all 7(gulp) of our little languages and they all looked more 
DP> intuitive to the average Joe (at least that is early feedback - first
formal review on Thursday).
 
>> It gives the curly brace crowd something to 'hold on to' when trying 
>> out the software. You may have struck a real chord here David. Is the 
>> idea to have HostObjectWrapper so that the Javascript can manipulate 
>> any object in the system if it can get a hold of it? If so, then JS 
>> is a valid alternative to St in an St VM.

DP> I think that HostObjectWrapper can be implemented as described (I 
DP> believe the Rhino guys did the same thing for Java).  This is going 
DP> to be appropriate for an audience that you want to give that kind of 
DP> power.  I also want to support a wrapper style that lets you have 
DP> fine-grained control over the permeability between ST and JS.  You 
DP> might want that control because of security concerns or because of 
DP> support concerns - you just might not want users to have access to ALL
objects in your image.

DP> I'm going to need to put together an example of integrating Smee 
DP> with a host application.  I'm thinking that with:Style: would make a 
DP> nice example.  What do you think?

DP> Other semi-random thoughts:
DP> - A JS XPath object would make a nice companion to the native RegExp
object.
DP> - JS in XSLT might be interesting - in both modes

[Smee-development] Hi to the list

[Michael Lucas-S. <mic...@sp...>]

Hello,

Thanks for inviting me to the list Dave,
I look forward to seeing what sorts of discussions are raised here.

-- 
Michael
http://www.softwarewithstyle.com
mic...@sp...

[Smee-development] test

[Pennell, D. <DPe...@qu...>]

Test.