[Glass] tODE

Tue Sep 9 10:30:25 PDT 2014

On Mon, Sep 8, 2014 at 10:36 PM, itlists at schrievkrom.de <
itlists at schrievkrom.de> wrote:

> Am 08.09.2014 um 22:27 schrieb Dale Henrichs:
>
> >
> > Is the requirement for 32 bit libraries a deal breaker and if so, how
> > many folks can't use gSdevKit if it requires 32 bit libraries?
> >
> > Dale
>
>  Not really, if it is a must, then it has to be installed - point.
>
>  But to be honest:
>
>  -> there are cases where adding the 32 bit subsystem is creating
> additional library problems. I've run into these problems several times
> in the past - even with my VASTServers. I had to include 32-bit
> libraries with my VASTServer application, because doing the equivalent
> 32bit library os-based-installation broke some of the 64 bit libraries
> (and yes i know: that should never happen).

I ran into a bit of that yesterday as I was trying to get the proper set of
32-bit libraries installed for Pharo, but I think I at elast found the
minimal set of libraries that needed to be installed, so that unwanted side
effects should be minimized ...

> If these problems happen,
> then you are really pissed off - and you get the views from people like:
> "hey programmer, use the right tools and not your 'I do all my stuff in
> ..' IDE.
>

I am not a fan of "do everything in the IDE", but I am a fan of being able
to write scripts in Smalltalk and I am happy to see Pharo move in the
direction of making it easier to run a headless scripting vm ...

Frankly I was able to pull together the GsDevKit in a matter of a week or
so because I was able to write my scripts in Smalltalk and I didn't have to
go through the pain of writing them in bash...

tODE is also breaking away from the "do everything in the IDE" as well ...
the importance of using Smalltalk on the client is that I can seamlessly
invoke tODE commands and GUARANTEE that the batch scripts run at the
command line run exactly the same way that the command runs when invoked
from within the tODE shell or when invoked from a menu in the GUI ...

The issue is that Pharo (along with other Smalltalks) has been a bit behind
in converting to 64-bit vms, but the work is being done and it is just a
matter of time

>
>  -> using Pharo as a scripting language ... well that's a suboptimal
> approach. When one wants to have scripting language then use a real
> scripting language. Perhaps its better to install Ruby or stuff like
> this - pretty good development languages and very well suited to
> scripting and easy to install and some kind of mainstream. This has
> nothing to do with Smalltalk itself: I would also not use C# or Java for
> such a scripting approach.
>

I don't necessarily agree that it is a suboptimal approach ... As I
mentioned earlier, by leaning on Pharo for my scripting language, I am able
to seamlessly invoke tODE commands or run arbitrary Smalltalk commands in
GemStone as needed by the script that I am writing. If I were to use
another language I would be faced with a much larger challenge ...

>
>  -> I suppose that Pharo might run in a true-headless server computer or
> do you need to install additional libraries to make this happen. In the
> past the so called true-headless mode was not such a true headless-mde.
>
> Regarding where DevKit should be placed ... well it was not clear for
> me, that the SDK now is also the place for the database and their
> extents. Its ok, but that should be mentioned - perhaps due to
> partitions size considerations. Actually I would make a strong line
> between the product and database Gemstone and the SDK - and this should
> be made visible also in the installation locations.

I think that the interesting piece of the GsDevKit is the structure that is
provided ... a regular structure makes it possible to write scripts that
can be used in production and reduce the number of custom scripts that are
required ... I broke out the various directories: logs, extents, tranlogs
precisely because in a production environment it makes sense to locate
these directories on different partitions and my expectations are that one
would use symbolic links and locate the directories on separate partitions
...

On the one hand it is ludicrous to think that the GsDevKit
structure/scripts  would be sufficient for all production scenarios, but I
do believe that the GsDevKit structure/scripts will make it easier for
folks to move into production and get to the point where they have enough
knowledge and experience with the system to make the next level of
structural and scripting decisions ...

Finally, I do expect GsDevKit to evolve ... and would appreciate concrete
suggestions as to changes that should be made to the structure ... Mariano
has already made some contributions in this area with specific
suggestions[1] for changes and I welcome more suggestions and discussions
about specific things that could/should be done ....

I would love to have contributions with improvements to the documentation
and/or scripts as well ...

I don't think that I should be the only person doing the work:)

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/issues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140909/60823089/attachment.html>