.st file naming

Hi,

while playing with GST, I found bit difficult to navigate
through code. For example, source code for class Exception
is in file kernel/ExcHandling.st. So I have to grep all the time.

I wonder why is it so? Wouldn't it be better to have one file
per class name, like in Java? Similar scheme is used in Smalltalk/X
and works just fine.
Also this would make tool implementation a lot easier - for instance
I'd like to be able to commit changes right from the browser.

Best, Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, Apr 03, 2015 at 12:07:20PM +0100, Jan Vrany wrote:

Hi!

> Also this would make tool implementation a lot easier - for instance
> I'd like to be able to commit changes right from the browser.

yes, some of this appears to come from a time where 8.3 was
the rule for filenames.

The question is how far we want/can go. In Gemstone/S, Pharo
there is a push to "filetree". There a class is spread over
a directory hieracy. E.g. like this:

        ClassName.class/
                        instance/
                                fooSelector.st
                        class/
                                classSideSelector
                        meta informationen..

        Extension.extension/
                ..

now this is nice for automatic tools (e.g. move a method
is a move of a file). Even for "recording changes" it is
quite nice but the downside is that "git grep" and reading
a single class at a time is difficult.

do you have an idea on how to move forward?

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 03/04/2015 13:07, Jan Vrany wrote:
> while playing with GST, I found bit difficult to navigate
> through code. For example, source code for class Exception
> is in file kernel/ExcHandling.st. So I have to grep all the time.
>
> I wonder why is it so? Wouldn't it be better to have one file
> per class name, like in Java?

Even in Java this is not completely true, as you have inner classes.

In GNU Smalltalk most classes have a 1:1 correspondence with files.  In
the case of ExcHandling.st, the reason why you have two files is
historical---that file used to have the whole implementation of
instance-based (IBM Smalltalk) exceptions, including bits now in
BlkClosure.st.  Splitting it in Exception.st and ExceptionSet.st would
make a lot of sense, and there are probably some similar cases elsewhere.

When splitting files one could take the occasion for creating
subdirectories of kernel/ as well.

At the same time, I think it would be pointless to split AnsiExcept.st
in 40 or 50 files.  Sure, you can, but the kernel GNU Smalltalk code is
not meant to be edited in a browser, since it needs to redefine some
methods during initialization and the order of the doits (Evals) is very
important too.

That said, the 14 character limitation is completely obsolete and it's
certainly okay to make file names longer if desired.

> Similar scheme is used in Smalltalk/X
> and works just fine.
> Also this would make tool implementation a lot easier - for instance
> I'd like to be able to commit changes right from the browser.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,
> Even in Java this is not completely true, as you have inner classes.
> On Fri, 2015-04-03 at 22:32 +0200, Paolo Bonzini wrote:

> On 03/04/2015 13:07, Jan Vrany wrote:
> > while playing with GST, I found bit difficult to navigate
> > through code. For example, source code for class Exception
> > is in file kernel/ExcHandling.st. So I have to grep all the time.
> >
> > I wonder why is it so? Wouldn't it be better to have one file
> > per class name, like in Java?
>

Indeed, but still, much more predictable.

> In GNU Smalltalk most classes have a 1:1 correspondence with files.  In
> the case of ExcHandling.st, the reason why you have two files is
> historical---that file used to have the whole implementation of
> instance-based (IBM Smalltalk) exceptions, including bits now in
> BlkClosure.st.  Splitting it in Exception.st and ExceptionSet.st would
> make a lot of sense, and there are probably some similar cases elsewhere.
>
> When splitting files one could take the occasion for creating
> subdirectories of kernel/ as well.

> At the same time, I think it would be pointless to split AnsiExcept.st
> in 40 or 50 files.  

Why it would be pointless?

> Sure, you can, but the kernel GNU Smalltalk code is
> not meant to be edited in a browser,

Well, this sort of spoils the whole idea of having smalltalkish
IDE...

> since it needs to redefine some
> methods during initialization and the order of the doits (Evals) is very
> important too.

Yeah, I feared that there are cases like this. But maybe we can work out
a way to solve this...

Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, Apr 04, 2015 at 07:37:36AM +0100, Jan Vrany wrote:

> I would not go that way. The only reason for this is to track
> method moves. After some 10 years of Smalltalk development,
> I don't think this is so important.

The other part of it is to be able to more easily export/import
code from Pharo. There is a lot of activity/packages and it would
be nice to support filetree in some form.


> Second, editing this by hand is a nightmare. After all, GST syntax
> was changed to facilitate hand-editing better, wasn't it?

It was before my time but yes, the current syntax is certainly
more fun than fileout :)

> Third, this would be nightmare to implement in a VM as the VM
> currently loads and compiles .st files when assembling a kernel
> and loading packages. There will be a need for a JSON parser, too.
> (I'd like to nuke the whole parsing and compilation logic out of the
> VM, but let's leave this for later :-)

Good points too.


> Yes :-) One can write a code that file outs a package (treating kernel
> as package like any other) and just read into the image and then spit
> out new files.
> One problem is that - AFAIK - there's no way to figure out to which
> "package" given code element belongs. So first step would be to add
> a reflection API for that.
> The idea is to keep reference to package object in each class and
> in method info.

Yes, that would be great! You would need to track classes and
methods (e.g. extensions)? Would we want that inside the Class
and CompiledMethod or have a "registry"? So we could have a
Registry package and VisualGST is loading it first?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, 2015-04-04 at 18:12 +0200, Holger Hans Peter Freyther wrote:
> On Sat, Apr 04, 2015 at 07:37:36AM +0100, Jan Vrany wrote:
>
> > I would not go that way. The only reason for this is to track
> > method moves. After some 10 years of Smalltalk development,
> > I don't think this is so important.
>
> The other part of it is to be able to more easily export/import
> code from Pharo. There is a lot of activity/packages and it would
> be nice to support filetree in some form.

Well, you can still have a Cypress reader/writer (which is a format of a
(git)filetree - https://github.com/CampSmalltalk/Cypress ) and
use it to import/export.
In my experience, as of today it's still much simpler just to port
monticello and read/save to monticello when one has to work
with Pharo/Squeak code.

Yes, each method and package should know its package. In a future,
each instvar and annotation too, but we're not yet there (no smalltalk
is).

I would strongly suggest to keep that within Class and CompiledMethod
instances. Doing it otherwise (i.e., registry) is just unnecessary
complication because then you must make sure you are always in sync.  
This is tricky to do, Pharo's RPackage is a an example of it.
Another complication would come into the play if you - as you suggested
- would like to have it as non-kernel loadable package. Then you somehow
would have to initialize the registry so also a kernel methods and all
packages that happen to be loaded before are properly packaged. Tricky
given that the goal of the "registry" package is to track packages :-)

The only reason for having it external in "registry" package I can think
of is a memory consideration - no "registry" package loaded, less memory
consumed. BUT: for deployment on memory constrained systems you can
always drop complete MethodInfo (held by CompiledMethod) to save memory.
Similar trick could be done for classes by introducing "ClassInfo" class
which would keep
package, category, and so on. This way, you save even more memory.

Does it make sense?

Best, Jan




_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, Apr 07, 2015 at 08:35:44AM +0100, Jan Vrany wrote:

> Well, you can still have a Cypress reader/writer (which is a format of a
> (git)filetree - https://github.com/CampSmalltalk/Cypress ) and
> use it to import/export.
> In my experience, as of today it's still much simpler just to port
> monticello and read/save to monticello when one has to work
> with Pharo/Squeak code.

Yes, I started twice with porting Monticello and didn't
complete it. Did you get further? Did you start with Pharo
or the Gemstone/S version? What do you do with traits and
other items we don't support yet? How to resolve a conflict
when loading?

I would have simply marked everything as "kernel" that is loaded
before the registry package. The benefit of a registry is that
depending on your storage structure you don't need to walk all
classes/compiled methods to find the ones that belong to a package.



> The only reason for having it external in "registry" package I can think
> of is a memory consideration - no "registry" package loaded, less memory
> consumed. BUT: for deployment on memory constrained systems you can
> always drop complete MethodInfo (held by CompiledMethod) to save memory.
> Similar trick could be done for classes by introducing "ClassInfo" class
> which would keep
> package, category, and so on. This way, you save even more memory.
>
> Does it make sense?

yes, it does counter my argument of just having an "external"
registry. Let's see if Paolo comments on "ClassInfo".

holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2015-04-07 at 15:52 +0200, Holger Hans Peter Freyther wrote:
I ported Monticello once to Smalltalk/X
( http://cvs.smalltalk-x.de/stx/goodies/monticello/ )
This one is fully functional and I used it successfully when
importing/exporting code from/for Squeak / Pharo guys.
I did it by pair-programming with Dale who ported it to
GemStone/S, so he already knew all it's dark corners and
peculiarities.

> Did you start with Pharo
> or the Gemstone/S version?

With Pharo/Squeak version but Dale told me ehat to pick
and what to throw away as not necessary (was quite a lot of stuff!)

> What do you do with traits and
> other items we don't support yet?

In St/X an error is thrown when a trait is encountered.

> How to resolve a conflict
> when loading?

What sorts of conflicts?

Best, Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

But then the package to which certain code element belongs would
depend on in which order you load packages. Very bad IMO.
Alternatively, you may have it as prerequisite of every package,
but that's bit silly :-)

> The benefit of a registry is that
> depending on your storage structure you don't need to walk all
> classes/compiled methods to find the ones that belong to a package.
>
True. But how often one need to do that? When you commit or when
one want to display code that belongs to a package. Both are not
performance-critical operations and walking through all classes is
fast enough.

Anyway, having this feature in kernel or in external package is
orthogonal to external data structure or reference from class(info) and
method(info)

There's one more complication to keep in mind, independent of above.
overwrites have to be handled too. A method has to keep the overwritten
method. Again, one can keep it in MethodInfo...
Yes. Paolo?

Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, Apr 07, 2015 at 05:28:14PM +0100, Jan Vrany wrote:

> But then the package to which certain code element belongs would
> depend on in which order you load packages. Very bad IMO.
> Alternatively, you may have it as prerequisite of every package,
> but that's bit silly :-)

Well, if you run VisualGST.. you will load it first. When I
run my deployment image.. I don't load it as size and performance
matters (I deploy on a ARM7TDMI system..)


Okay, true.

> Yes. Paolo?

I care about memory increase of a plain kernel/image as well. How
much time do you have for GNU Smalltalk?


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, Apr 07, 2015 at 05:16:28PM +0100, Jan Vrany wrote:

> I ported Monticello once to Smalltalk/X
> ( http://cvs.smalltalk-x.de/stx/goodies/monticello/ )
> This one is fully functional and I used it successfully when
> importing/exporting code from/for Squeak / Pharo guys.
> I did it by pair-programming with Dale who ported it to
> GemStone/S, so he already knew all it's dark corners and
> peculiarities.

Ah, maybe we can do the same for GNU/Smalltalk?

> In St/X an error is thrown when a trait is encountered.

Okay, so you need to fix it in Pharo before you can import
it?

> What sorts of conflicts?

The trait, subclassing something that doesn't exist, etc.
I know Gemstone/S doesn't have it but what I generally want.


* Load original code
* Fix subclasses/inheritance while loading
* Take a snapshot
* Attempt to get tests working..
* Make release...

preferable everything from within a graphical environment.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2015-04-07 at 19:56 +0200, Holger Hans Peter Freyther wrote:
> On Tue, Apr 07, 2015 at 05:28:14PM +0100, Jan Vrany wrote:
>
> > But then the package to which certain code element belongs would
> > depend on in which order you load packages. Very bad IMO.
> > Alternatively, you may have it as prerequisite of every package,
> > but that's bit silly :-)
>
> Well, if you run VisualGST.. you will load it first.

Right, but still, what prevents you from loading say
HTTP server first and VisualGST later?

OK, let's do some experiments first to get some data.

> How
> much time do you have for GNU Smalltalk?
>

Not much. Half a day per week, at best.



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,
> OK, let's do some experiments first to get some data.

I did some quick changes to keep track of packages as
I suggested:

https://github.com/janvrany/gst/commit/0123cc6d00fdf0cf0781b308ebbe4ba96e70292e

This is certainly not complete: no package tracking in classes (i.e.,
ClassInfo), no API yet, no overwrites support, no support in browser,
no extensive testing, ...

Best, Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

neat! How confident are you that Current and _gst_current_package will
stay in sync? With the failing primitive we mostly avoid having to deal with
protecting the package in C but this assumes that from failing to assignment
nothing else will be executed. :)

holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

sorry, I overlooked this post...

I have same level of confidence as for Namespace and _gst_current_namespace.
I just followed the same pattern.
Not that I particularly like this pattern - It would be lot better to
have an API to access class vars from the C. Then we won't have this problem
at all (and won't depend that much on a particular implementation of
a memory manager :-)

>
> With the failing primitive we mostly avoid having to deal with
> protecting the package in C
>

Right.

>  but this assumes that from failing to assignment
>  nothing else will be executed. :)
>

I think the code is correct. It reads:

1209   Package class >> current: aPackage [
1210        <category: 'accessing'>
1211        <primitive: VMpr_Package_setCurrent>
1212    Current := aPackage
1214   ]

Even if a lot of GC happens in between the assignment
in a primitive and in the method above, the package
object cannot be GC'd because it's held by the method's
context. When the context is gone, it's already assigned
in the class var, so it cannot be GC'd.

Jan


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,I'm New from Canada