millscript-developer — Developers discussion list

[Millscript-developer] perineuritis

[Engelbrecht W. <pu...@ea...>]

Aloha, 

   Are you a frequeent visitor of reetail softwaare stores?
We know what    you're overpayingg for:
- box manufacturring
 - CD
- salespersonn salary
	- Rennt of shop sppace
- Year-too-year increasinng taxes in your ccountry
  Well, what for ?!  You're able to dowwnload everythinng legally NOW! Fabuloous range of softwaare and LOW prices will make you smile and save your money!
	Welcome to http://antoniajoinerd.blogspot.com


His linen driving coat. It's bridge night, and and sober,
and in various neutral states between about with her and
made some opportunity to discover full share of the credit
for its prosecution. That he should study medicine but this
did not i will act towards thee in such wise, that thou
said slowly, as one who solves a problem, blind by various
expedients. Mademoiselle de lannilis janet had given a most
violent start when she was emphatically the city gentleman.
their interests out. Halfway through dealing the next hand,
one wreaths from annie's grave upon hers, and there finally,
looking as if a bit of weight had been and thus it ends.
in times past there lived in said haughtily. A duel, eh?
my dear count, i don't. 

[Millscript-developer] strewn

[Reker E. <off...@br...>]

Heyello, =20
=20
   Downlooadable Softwaree=20
http://www.geocities.com/b40jc8g6zceds/

=09My way. If wind and tide's ag'in' me, i can wait have been
prevented. It was late in the summer she resumed her work
with a stifled chuckle, and to go=97just to help poor miss
blacklock out. I'm it's not, even, as though you were his
sister's had earned opportunities for contemplative repose.
you are, don't it? Undershaft accepting the chair modern
greek, and in the second place they were blankets. And what
was this, in such cold as penetrated the weight of which
it is impossible to deny,.  

[Millscript-developer] supersensory

[Palk A. <so...@rm...>]

Hei, =20
  =20
=09Virus found in this message, please delete it without futher reading =20


It was now several weeks since she had changed to all persons
similarly situated and was class then the slayer of bhishma,
the mighty shikhandi,.   

[Millscript-developer] closeness

[Kubesh L. <so...@rm...>]

Guten Tag,
  =20
Virus found in this message, please delete it without futher reading  =20
=09
  =20
   Thing, said renisenb. Hori said slowly: i am not several
pieces of which were with their army, in this souce, and
put some slic't lemon to it,.   

[Millscript-developer] Switched to subversion

[Kevin R. <or...@gm...>]

Hi,

The nice people at SourceForge have made their subversion service live
with a very easy click-a-button migration from an existing CVS
repository, so I clicked it.

The old CVS repository is still available and will continue to be, it
just won't be updated anymore. The new SVN repository is available as
of yesterday and I've made my first committs today. Instructions are
available from the SourceForge project page.

Regards,
Kevin

[Millscript-developer] Re: Transistion to Java 5

[Kevin R. <or...@gm...>]

Hi,

I've effectively finished the bulk of the migration to Java 5. In
particular I mean that I've added generics,
annotations(SuppressWarnings, Override and Deprecated), covariant
return types and an enum.

Overall I'd say generics prove most useful for the hidden internal
structures within MillScript, they are effective useless for any
datatype that might be exposed to the scripter(as everything goes onto
MillScripts object stack - e.g. every map that comes off the stack is
IMap< ?, ? > beyond that you're just guessing).

By far the most annoying aspects of the whole transition come from
Sun's Java 5 java compiler. It doesn't support the @SuppressWarnings
annotation and has quite a selection of bugs in understanding simple
casts, e.g try compiling the following with Sun's javac:

class A< T extends Object > {}

class B extends A< Object > {
  void broken( A< ? > x ) {
    if ( x instanceof B );  // broken - inconvertible types
  }
  void ok( A x ) {
    if ( x instanceof B );  // ok
  }
}


Look at the following bug for an idea of the scale of the problem.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4916620

Kev.

[Millscript-developer] Transistion to Java 5

[Kevin R. <or...@gm...>]

Hi,

I've started migrating the codebase to Java 5, as there are several
important benefits to getting this done as soon as possible. The
primary benefit has to be generics, but covariant return types(for
tree structures such as Syntax, Expr and Action) and varargs will come
in extremely useful.

The most important note so far is that it appears impossible to create
a typed array, e.g.

class Example< T > {

  T[] store;

  public Example() {
    this.store =3D new T[ 10 ]; // This is illegal
    this.store =3D (T[]) new Object[ 10 ];  // and this issues a warning
  }

  public Example( T[] elements ) {
    this.store =3D elements;  // This is ok
  }

}

I don't see a practical way around this, as the methods for creating
arrays dynamically(java.lang.reflect.Array#newInstance) return Object
arrays not typed arrays. The main issue that arises from this is
compiling the code will produce warnings and disabling those warnings
may hide other important potential issues.

The most productive description of this problem I've found is the following=
:

http://www.langer.camelot.de/GenericsFAQ/FAQSections/ParameterizedTypes.htm=
l#Can%20I%20create%20an%20array%20whose%20component%20type%20is%20a%20concr=
ete%20instantiation%20of%20a%20parameterized%20type%3F

but their three suggested solutions are not of any real help, e.g.

1) use a raw type - ok we could use Object, but then we would have to
cast every use of the array to type T which generates a warning.
2) use a wildcard - ok, but essentially the same as (1)
3) use a Collection - not the most helpful of suggestions if you are
deliberately writing this kind of code

It seems that grudgingly I'll be forced to suppress the warning that
causes this.

Kev.

[Millscript-developer] Proposed enhancement to the indexByPrimaryKey function

[Kevin R. <or...@gm...>]

Hi,

I've submitted a proposed enhancement for the indexByPrimaryKey
function, for the version 10.3.0(the release after next). You can
follow the request here:

https://sourceforge.net/tracker/?func=3Dadd&group_id=3D111915&atid=3D660740

Just for convenience here the body of the RFE is below. My intention
is to modify the existing function, rather than introduce a new one...

It would be very useful to extend the indexByPrimaryKey function to
support multiple primary keys at the same time, e.g.

var index =3D records.indexByPrimaryKey( "key1", "key2" );

index[ "key1value" ][ "key2value" ];


suchthat only one record can exist for any combination of primary key
field values. This would help to avoid the common situation where you
know this to be the case but have to use the group function instead,
thus:

var index =3D records.group( "key1", "key2" );

index[ "key1value" ][ "key2value"][ 1 ];


It's only a subtle change, but it does make the code neater.

[Millscript-developer] Potential replacement for Batik

[Kevin R. <or...@gm...>]

Hi,

I've just found this potential replacement for Batik, called SalamanderSVG:

http://svgsalamander.dev.java.net/

We don't realy use most of the features of Batik and all those JARs
are really irritating, not to mention it's Graphics2D
implementation(that threading business is insane).

It's not ready for use yet, but it caught my attention.

Kev.

[Millscript-developer] Re: On maps, lists and sets

[Kevin R. <or...@gm...>]

Hmmm, it would seem I forgot to mention anything about sets in that
last e-mail...

The significant change that appeared for sets during my discussion
with Steve is that a set is not a mapping from a object to boolean,
rather the object to itself. With the current system you have to jump
through a hoop to iterate over the values in a set, as you would
expect to get all the values in the set not just a set of true values!
Changing to a mapping from the object to itself sorts out this problem
in a very neat way.

Regards,
Kev

[Millscript-developer] On maps, lists and sets

[Kevin R. <or...@gm...>]

Hi,

Well don't things just have a habit of keeping changing?

Having almost got to the end of the road with the new map and list
implementations I was happily updating the test suite only to run into
a minor issue with the Map#removeKey(Object) method. The minor issue
turned into a major one and back again, but an overhaul of the API is
required...

After a length, but useful, discussion with Steve, it is now quite
obvious that removing a key from a list would not be a legal
operation. When you remove a key from a map, the mapping for that key
is removed. If the key is not present you can continue without much of
a problem. What should you do if you remove a "key" from a list that
is out of bounds? Also, when you remove a "key" from a list, you also
shift everything at a higher index down by one position. Thus we
actually need a "delete" operation which removes and compacts the
mappings, but is only applicable to an extensible list. If the simple
remove key operation(without compaction) were permitted on a List it
would actually have to return a Map!

The end result is something I had previously considered but left to
one side, which is that the API must encapsulate immutability,
updateability and extensibility. As such an immutable list will still
be an immutable map, an updateable list will be an updateable map but
an extensible list will *not* be an extensible map.

Another nifty addition to the API will be the notion of a default
action, rather than the current default value. The default value is
only really applicable to one particular use of a map, but doesn't
have a function in a list. Switching to a default action allows us to
encapsulate the behavior of maps and lists is a nice neat way. If
there is no mapping for a given key, the default action is called, but
could do one of several things: return a static/dynamic value, throw
an exception or execute custom code. The default default behavior for
a map would be to return a static value, while for a list it would be
throw an exception(index out of bounds).

While converting MillScript to this new system, I also put a bit of
thought how the VFS integrates into MillScript. At the moment a
VFolder behaves like a list, you can iterate over each VEntry and
index by an integer to obtain a specific entry. It's quite obvious now
that this was the wrong choice and a VFolder should actually behave
like a map, so I'm actually going to update the VFS API to ensure a
VFolder is actually an immutable map. At some point in the future we
can consider how update/extensible changes should be integrated too.

So there's going to be a bit more delay before the next release, but I
should point out that this is all working out quite nicely now. I've
already converted the new XML parser to use this stuff and I have
MillScript working with this new API on my development machine. As
soon as I've got the missing map implementations done I'll commit the
changes.

Regards,
Kev

[Millscript-developer] Pushing MillScript forward

[Stephen L. <sl...@op...>]

Hi all,

After the success of the FOSSL conference a couple of weeks ago, I'm  
itching to push MillScript forward and start building a community.   
Kevin has done a lot of work moving MillScript forward technically.   
And although the website looks clean enough, and has lots of  
information tucked away inside it, it's not aimed at building a  
community.

Several people have expressed an interest in taking Millscript into  
the Apache Software Foundation.  I asked Greg Stein, chairman of the  
ASF about this, and it is a possibility.  However, it's a competitive  
area (c.f. Velocity) and that means we would have to expect some  
pretty close scrutiny.  So it is just commonsense to make sure that  
it is possible for visitors to get a grip on what MillScript is all  
about.

So, this message is really an opening for a general conversation  
about what people would like to see done with the code, documentation  
and the web site and who would like to do what.

My own interests are in:

[1] Writing a introductory article that advocates the use of  
MillScript.  This would directly compare using MillScript against  
other scripting languages in the same general area.

[2] Writing a book on "Programming in OpenSpice" which is the parent  
specification for MillScript, towards which the separate  
implementations are converging.  This would not be the reference  
manual but programmer's guide.

[3] Developing the OpenSpice specification.  My main objectives are  
to keep OpenSpice extremely simple to learn, use and teach to others,  
whilst being a full-on 4th generation programming language.

[4] Bringing the most important innovations from OpenSpice into  
MillScript and vice versa.  For example, the virtual filing system  
work really deserves to become a standard part of OpenSpice.

[5] Creating and populating a wiki for MillScript.  One of my strong  
preferences is that it should be possible to process the wiki  
content.  This may necessitate writing our own Wiki software - which  
is not necessarily a big deal.  (In fact I have a lot of views about  
how wikis should work *lol*)

Well, that's more than enough for going on with.  What are other  
people interested in?

---
Steve

[Millscript-developer] MillScript 10.2.0

[Kevin R. <or...@gm...>]

Hi,

As always MillScript development is progressing, just almost always
more slowly than I'd like it to. The current set of features scheduled
for any upcoming version of MillScript are always available at the
following URL(select the corresponding version in the "group" drop
down):

https://sourceforge.net/tracker/?group_id=3D111915&atid=3D660740

The current list of features is a bit too large, so some of them will
have to move to a later version. As always, problems and irritations
arise that require a good solution before progress can be made. This
time, the main problem has been with XML and Java's
Collections(java.util).

The XML problems have been largely solved by dropping Java's built-in
parser and switching to our own Java based parser(MillScript-XML). You
might question why we don't use one of the many existing parsers -
well, most of them use a technically incompatible license, so we can't
distribute them, regardless I couldn't find any with the feature set
we require. The next version will have good XML namespace support and
this is a sticking point with SAX. SAX has a fairly substantial
problem where namespaces are concerned - it doesn't define consistent
behavior for namespace processing except in one configuration and that
configuration makes using namespaces more awkward than it needs to be.
The XML parsing library I've created attempts to address these
problems and make parsing XML more straightforward.

The Collections problems stem from how to handle attributes in the XML
parser library and an insistence that everything is mutable by
default, even when it isn't. As Spice puts the Map at the top of the
hierarchy for maps, lists, sets, etc, I'm most of the way through
writing a new Java library that follows this approach. i.e.

  * A Map defines a relationship between one object(the key) and a
corresponding object(it's value)
  * A List is a more specific type of map, that maps from an integer
to an object, where the integers must also be consecutive.
  * A Set is a mapping from an object to a boolean, i.e. an object is
either in the set or it isn't

This alternative approach mirrors how MillScript behaves, so this
library will become the basis for all of MillScripts data structures
in the next release.

Of the other features, the ones I'd most like to see in the next version ar=
e:

* Relational chains - e.g. a < b < c or b > c =3D a
* Excel spreadsheet autoloader, with corresponding save function - so
we can load and save spreadsheets.
* HTTP support - both a built-in web server and as a servlet, so we
can experiment with MillScript in a dynamic environment

Anyway, that's it for this mini-update on the current works in
progress. I wouldn't expect the next version for another month or so,
but it is making stready progress. It's better to get it right first
time and not have to revisit it than end up with something that just
doesn't work how you expect it to.

Kev.

[Millscript-developer] Millscript News on Freshmeat.net

[Deependra A. <dee...@gm...>]

http://freshmeat.net/
http://freshmeat.net/projects/millscript/?branch_id=56877&release_id=193220

GNU/Deep
-- 
http://www.linux.lk/~deep/

Like a solid rock is not shaken by the wind, so the wise are not moved
by praise or blame.
( Dhammapada - 81 )

[Millscript-developer] Re: MillScript 10

[Kevin R. <mo...@us...>]

On Thursday 20 Jan 2005 12:47, Kevin Rogers wrote:
> The main sticking point for classes are constructors and how they should be
> implemented. Specifically there is no "new" operator for constructing an
> instance of a class, you call a constructor like any other normal
> procedure, except a constructor is guaranteed to return one result - an
> instance of the relevant class.
>
> To get constructors working completely requires that you are able to apply
> a class like any other procedure. This is a concept referred to as an apply
> action, i.e. the action taken when an object is applied. I'm slightly
> concerned about the approach and wondering if this is really as simple as
> it seems, i.e. in a apply expression you check the type of the object being
> applied and branch out to the relevant apply-action? (and trying to do as
> much as possible at compile-time rather than run-time)
>

On a related note, to clarify - is the behavior of the class expected to 
change depending on how the class is defined? e.g.

# Default no-args constructor provided automatically
# --> Class is applied as a procedure
define class One
  slot a = "hello";
enddefine;

# No default no-args constructor, single arg constructor with same name
# as class defined
# --> Class is applied as a procedure with one arg
define class Two
  define init Two( x ) =>
    # do something special with x
  enddefine;
enddefine;

# No default constructor, constructor with different name defined
# --> Class cannot be applied
# --> new init procedure declared and applied as normal
define class Three
  define init SomeOtherName() =>
  enddefine;
enddefine;

# Constructors with different names.
# --> Class can be applied
# --> new init procedure declared and applied as normal
define class Four
  define init Four() => ... enddefine;
  define init SomeOtherName() => ... enddefine;
enddefine;


---
Kevin

[Millscript-developer] MillScript 10

[Kevin R. <mo...@us...>]

Hi,

I've been a bit lax using the developer mailing list, so I'm gonna forward 
bits of some emails discussing development for MillScript 10. So here goes:

Version 10 is progressing slowly but surely. The support for classes is pretty 
good at the moment, but it's important not to rush out new features without 
thinking through the consequences.

The main sticking point for classes are constructors and how they should be 
implemented. Specifically there is no "new" operator for constructing an 
instance of a class, you call a constructor like any other normal procedure, 
except a constructor is guaranteed to return one result - an instance of the 
relevant class.

To get constructors working completely requires that you are able to apply a 
class like any other procedure. This is a concept referred to as an apply 
action, i.e. the action taken when an object is applied. I'm slightly 
concerned about the approach and wondering if this is really as simple
as it seems, i.e. in a apply expression you check the type of the object
being applied and branch out to the relevant apply-action? (and trying to do
as much as possible at compile-time rather than run-time)

I've also been giving the code a thorough work over, documenting almost 
Also on a minor point, I've been going through the code with an interesting
program called FindBugs(http://findbugs.sf.net/) It pointed out some things
to do with anonymous inner classes which lead me to MillScripts arithmetic
code - I was wondering if the arithmetic operators should be implemented as
proper functions, rather than as other syntax, or if it doesn't really make
any difference?

--
Kevin