Re: [Pharo-users] Pharo-users Digest, Vol 57, Issue 39

2018-01-15 Thread Ian Ian
W.R.T Database Connectivity:

Hi All,

The database connectivity issue as discussed is near and dear to my
evaluation of Smalltalk(s).  It is a huge problem/stumbling block as I see
it.

Here Is a cut and paste of my replay to the Gemstone users group:

>
Hi Dale,

I am evaluating Gemstone as an application server/big data repository.
Hence my confusion up till now.

I work for an organization that has rather large data storage requirements
(understatement:  into the 100's of petabyte range).

Currently, several independent Apache Hadoop stacks are used to manage this
data.  There are several serious issues that are evident with this setup,
prime of which is object to relational mapping errors (as datasets in a
given space change over time - data is mandated to be kept into perpetuity)
regardless of whether the database is NoSQL, SQL of any other schema.  The
issue bubbles up into the organization application layers of many diverse
and distributed verticals.  Maintenance of the system is not trivial and is
very expensive and time consuming.

We use virtualization (in the VMWare sense) to create views into the data.
Generally, access is a split between virtualized kiosk systems, another
level of indirection, where by mandate, we must now archive the state of
the vm's as well as business data, and direct workstation access,   Not
fun, error prone and hardware intensive (from a data storage perspective).

As I have been reading about object databases and what they are said to buy
in terms of efficiency (objects being stored natively and directly) coupled
with the fact the we are virtualizing everything we can, I, along with a
couple of colleagues, thought that we should take a look at what new
(laugh) technologies were available.

After a little time I came across Gemstone.  Did my reading and research
and after a period of semantic confusion (still going) became enamored with
the possibilities.

All this said, from a network, sys admin point of view, an image that
contains the application and it's objects is a godsend if object
persistence was guaranteed.  It would allow me to archive a self contained
living blob that manages its own living state (in the VMWare snapshot
sense) and at the same time the data is available to other blobs/views
(seaside).

On views in to the data store:

Currently data mining occurs on the application layer (rather than database
level views).  Various development groups create views (applications) to
access (possibly update, if they are the owning group) the data.  As
mandate trickle (waterfall) from above new data points can be added or
removed (some of the mandate for this is governed by changing regulations -
in other words it must be done regardless of the technical difficulties
involved).  You can image the difficulties and manpower involved.

This brings me back to the application server.  Currently, whatever tool a
group uses to access the data, be it browser, remote client application,
whatever have you (generally based on the skill sets in the group),
requires a set of policies and procedures wrapped around the effort
(mandated disaster recovery and etc...).  Tones of work that can never be
standardized in any way but nevertheless must be documented and managed.

Okay (to long winded self):

Having spent some time looking at this problem from a smalltalk, image
virtualization, integrated application management perspective, all my
issues could be alleviated within a single technology.  Yippee!

The spawning of an idea:

Amber -> Seaside -> Gemstone.  One language (integrated properly -> one
tool).

Amber:

*  Each group, with a small learning curve could create and manage their
own views into the data.
*  The serialized javascript, once the client was developed, could be
streamed from the application server (Seaside/Gemstone) on demand.  It just
becomes another object.

Seaside:

* Client interface manager transport system (HTTP) for any and all views.

Gemstone:

* Object level persistence with no forced mappings of any kind.
* Extensibility. (can gemstone handle data levels in the petadata range?)

Cool!:

* Users/Developers of the system have a completely controlled view into the
image/system (perhaps a clustered NginX front end?).
* Image access at the machine level is completely controlled/secure.
* Everything in one place with system knowledge transfer and expertise
leveraged vertically and horizontally.
* The images can easily be archived in whatever manner (at the bit level
using any version control system if desired) at whatever schedule.
* Another level of 'complete system' security achieved. (Way cool!!)
* Whole systems is a single entity!  Fantastical!
* A significantly smaller foot print.

* Cost reductions, increased efficiency all the way through...

Pipe dream?  Maybe but I think it is doable over time with smalltalk.  The
same system is not doable in any other way with any other technology
without extensive dollars and 

[Pharo-users] Iceberg regex

2017-12-26 Thread Ian Ian
Yes.  That is how it is on github but there are private hit serveers.  My
own, for example.

I found it usable after I changed the regex in both classes where it
exists.


On Dec 26, 2017 4:14 AM, <pharo-users-requ...@lists.pharo.org> wrote:

> Send Pharo-users mailing list submissions to
> pharo-users@lists.pharo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.pharo.org/mailman/listinfo/pharo-users_
> lists.pharo.org
> or, via email, send a message with subject or body 'help' to
> pharo-users-requ...@lists.pharo.org
>
> You can reach the person managing the list at
> pharo-users-ow...@lists.pharo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pharo-users digest..."
>
> Today's Topics:
>
>1. Re: Strange 'Connection closed while waiting for data.' Zinc
>   error (Yuriy Tymchuk)
>2. Re: Iceberg URL regex not matching how I would expect it to?
>   (Juli?n Maestri)
>3. Re: Strange 'Connection closed while waiting for data.' Zinc
>   error (Sven Van Caekenberghe)
>4. Breakpoints in Pharo (Andrei Stebakov)
>5. Re: Strange 'Connection closed while waiting for data.' Zinc
>   error (Yuriy Tymchuk)
>6. Re: Strange 'Connection closed while waiting for data.' Zinc
>   error (Sven Van Caekenberghe)
>
>
> -- Forwarded message --
> From: Yuriy Tymchuk <yuriy.tymc...@me.com>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 18:03:11 +0100
> Subject: Re: [Pharo-users] Strange 'Connection closed while waiting for
> data.' Zinc error
> Hi,
>
> setting the reuse timeout to 0 or making a one shot client does not help.
> But while googling I found the exact issue described on the Pharo issue
> tracker: https://pharo.fogbugz.com/f/cases/18588/
>
> The proposed workaround also worked for me:
> ZnNetworkingUtils default socketStreamClass: SocketStream.
>
> Cheers,
> Uko
>
> > On 25 Dec 2017, at 05:42, Andrew Glynn <aglyn...@gmail.com> wrote:
> >
> > The only time I've seen that behaviour is with the combination of a slow
> server and a proxy such as CloudFlare where the sysadmin has set tcp_wait
> to some ridiculously small number.  Have you tried setting the connection
> reuse timeout to 0, or setting 'beOneShot'?
> >
> > Zinc doesn't support the additions in HTTP/2, but I can't offhand think
> of any reason that should cause that specific behaviour. I've had
> sufficient problems with HTTP/2 over slow connections (I live where there
> are no land lines of any kind) that I replaced the HTTP/2 code in Nginx
> with code from pureftpd in order to access my server at home when I'm out.
> >
> > Andrew
> >
> > On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" <
> pharo-users-boun...@lists.pharo.org on behalf of yuriy.tymc...@me.com>
> wrote:
> >
> >Hi,
> >
> >I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they
> have a simple REST API). When I try to do a GET request with Zinc like this:
> >
> >ZnClient new
> >   url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731
> df/lights/';
> >   get
> >
> >I get a “ConnectionClosed: Connection closed while waiting for data”
> exception. The service provides a JSON response that I can get without a
> problem by using a web browser or curl. Also if I try to access fewer data
> (e.g. adding /1 to the url, so it gets only one resource) I don’t get the
> exception.
> >
> >What is even more strange, when I resume the exception I get the
> desired response i.e. this works:
> >
> >[ ZnClient new
> >   url: 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731
> df/lights/';
> >   get ]
> >
> >   on: ConnectionClosed
> >   do: [ :ex |
> >   ex resumeUnchecked: ex defaultResumeValue ]
> >
> >Of course I cannot share the server that is on my local network for
> resting, but maybe anyone knows it there are any known issues with Zinc, or
> if there are ways for me to debug the issue further.
> >
> >Cheers.
> >Uko
> >
> >[1]: https://www.developers.meethue.com
> >
> >
> >
> >
>
>
>
>
>
> -- Forwarded message --
> From: "Julián Maestri" <serp...@gmail.com>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 15:16:57 -0300
&

[Pharo-users] Thanks All.

2017-12-26 Thread Ian Ian
After some looking into it I believe Mongo Voyager is the easiest given the
current options.

Too bad Gemstone limits usage after a given number of Gems.

Too bad ObjectDB does as well.

Thanks all. :)

On Dec 25, 2017 12:00 PM, <pharo-users-requ...@lists.pharo.org> wrote:

> Send Pharo-users mailing list submissions to
> pharo-users@lists.pharo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.pharo.org/mailman/listinfo/pharo-users_
> lists.pharo.org
> or, via email, send a message with subject or body 'help' to
> pharo-users-requ...@lists.pharo.org
>
> You can reach the person managing the list at
> pharo-users-ow...@lists.pharo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pharo-users digest..."
>
> Today's Topics:
>
>1. Re: Object Persistence (Hilaire)
>2. Re: Object Persistence (Joachim Tuchel)
>3. Re: Object Persistence (Torsten Bergmann)
>4. Re: Object Persistence (Stephane Ducasse)
>
>
> -- Forwarded message --
> From: Hilaire <hila...@drgeo.eu>
> To: pharo-users@lists.pharo.org
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 12:08:08 +0100
> Subject: Re: [Pharo-users] Object Persistence
> Fuel (present in the image) is nice, but not compatible from one image
> version to another one.
>
> Hilaire
>
>
> Le 25/12/2017 à 10:43, Ian Ian a écrit :
>
>> Hi All,
>>
>> Thoughts of a purely OO nature?
>>
>> :)
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>
>
>
> -- Forwarded message --
> From: Joachim Tuchel <jtuc...@objektfabrik.de>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 12:54:10 +0100
> Subject: Re: [Pharo-users] Object Persistence
> Wasn’t there an attempt to port Magma over from Squeak? That would sound
> like a nice alternative. Or Gemstone, of course.
>
> > Am 25.12.2017 um 10:43 schrieb Ian Ian <icjohns...@gmail.com>:
> >
> > Hi All,
> >
> > Thoughts of a purely OO nature?
> >
> > :)
>
>
>
>
>
> -- Forwarded message --
> From: Torsten Bergmann <asta...@gmx.de>
> To: pharo-users@lists.pharo.org
> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Bcc:
> Date: Mon, 25 Dec 2017 14:13:37 +0100
> Subject: Re: [Pharo-users] Object Persistence
> Hi,
>
> with Voyage you can already use easy persistence in an OO way - with tiny
> (P)UnQlite up to Mongo.
>
> Check https://github.com/pharo-nosql
>
> Or you use Gemstone.
>
> For a full Magma version on Pharo:
> I doubt that will happen as Chris Muller was and still is more oriented
> towards Squeak as
> development platform. He is the author of Magma and beside the port it
> would cost him
> (or anyone who would do such a port) more effort to maintain another Pharo
> specific version.
>
> But maybe a Pharo client for a Squeak based Magma server is possible -
> with a Voyage wrapper.
>
> Bye
> T.
>
> > Gesendet: Montag, 25. Dezember 2017 um 12:54 Uhr
> > Von: "Joachim Tuchel" <jtuc...@objektfabrik.de>
> > An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>
> > Betreff: Re: [Pharo-users] Object Persistence
> >
> > Wasn’t there an attempt to port Magma over from Squeak? That would sound
> like a nice alternative. Or Gemstone, of course.
> >
> > > Am 25.12.2017 um 10:43 schrieb Ian Ian <icjohns...@gmail.com>:
> > >
> > > Hi All,
> > >
> > > Thoughts of a purely OO nature?
> > >
> > > :)
> >
> >
> >
>
>
>
>
> -- Forwarded message --
> From: Stephane Ducasse <stepharo.s...@gmail.com>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 16:01:15 +0100
> Subject: Re: [Pharo-users] Object Persistence
> the author of omnibase told me that he always wanted to port it to
> Pharo. But may be someone should do it.
> There is also VOSS that is open source even if GPL that could be
> ported to pharo but this is an effort too.
>
> Stef
>
> On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <icjohns...@gmail.com> wrote:
> > Hi All,
> >
> > Thoughts of a purely OO nature?
> >
> > :)
>
>
>
> ___
> Pharo-users mailing list
> Pharo-users@lists.pharo.org
> http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org
>
>


[Pharo-users] Object Persistence

2017-12-25 Thread Ian Ian
Hi All,

Thoughts of a purely OO nature?

:)


[Pharo-users] Iceberg URL regex not matching how I would expect it to?

2017-12-24 Thread Ian Ian
Hi All,

I am having trouble setting up iceberg to access my repository via ssh.

On the command line I assess it via:  git clone u...@server.com:/proj/proj.git
and all works as expected.

When adding trying to add the same repository to iceberg I get a parseUrl
error thrown from class IceScpRemote.  While debugging I see the following
regex:

matcher :=
'(ssh\://)?([\w\-]+@)?([\w\-.]+)(\:[\d]+)?(\:|/)/?([\w\-]+)/([\w\-]+)(\.git)?'
asRegex.

which parses usern...@server.com:/directory/proj.git.

However fails to parse:  usern...@server.com:/dir1/dir2/proj.git

The corrected version is as follows:

matcher := 
'(ssh\://)?([\w\-]+@)?([\w\-.]+)(\:[\d]+)?(\:|/)/?(([\w\-]+)/)+([\w\-]+)(\.git)?'
asRegex.

Questions:

Is this by design?
of the top of your head:  If I use the corrected version am I going to run
into other issues?


NB:  I am using 64 bit Pharo 6.0 Update: #60520

Thanks in advance,


Re: [Pharo-users] Irc

2017-12-21 Thread Ian Ian
Thanks Estoban.  I'll check out discord.  :)

BTW, I am new to smalltalk. New to Pharo.  Liking both!  :)

On Dec 21, 2017 8:45 AM, <pharo-users-requ...@lists.pharo.org> wrote:

Send Pharo-users mailing list submissions to
pharo-users@lists.pharo.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org
or, via email, send a message with subject or body 'help' to
pharo-users-requ...@lists.pharo.org

You can reach the person managing the list at
pharo-users-ow...@lists.pharo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pharo-users digest..."

Today's Topics:

   1. Re: Active IRC Chanel (Esteban Lorenzano)
   2. Re: Iceberg, Git and Package version (Esteban Lorenzano)
   3. Re: Iceberg, Git and Package version (Esteban Lorenzano)
   4. Hi, do I nowadays need any Id and psw, to log in smalltalk
  hub and others? (Janko Korelc)
   5. Re: Iceberg, Git and Package version (Vitor Medina Cruz)


-- Forwarded message --
From: Esteban Lorenzano <esteba...@gmail.com>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Cc:
Bcc:
Date: Thu, 21 Dec 2017 11:10:55 +0100
Subject: Re: [Pharo-users] Active IRC Chanel


> On 21 Dec 2017, at 08:27, Marcus Denker <marcus.den...@inria.fr> wrote:
>
>
>
>> On 21 Dec 2017, at 04:34, Ian Ian <icjohns...@gmail.com> wrote:
>>
>> Hi All,
>>
>> Is there an active IRC Chanel?
>
> No. There is (or was) an inactive one.
>
>
>> Read somewhere (can't remember) that there is one labeled #pharo.  Is
this true if so may I ask on which server it resides?
>>
>
>
> I guess it is still there, it was on freenode I think.
>
> The Discord chat is quite active. For me it works much better than IRC.
Maybe I had just a bad IRC
> client, but it never was a nice experience.

yes.
I don’t understand why, but #irc channel never worked while discord works
pretty well and is very active.
I mean… at the end, discord is no more than a glorified irc, but well… one
works and the other don’t :)

Esteban

>
>   Marcus





-- Forwarded message --
From: Esteban Lorenzano <esteba...@gmail.com>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Cc:
Bcc:
Date: Thu, 21 Dec 2017 11:22:59 +0100
Subject: Re: [Pharo-users] Iceberg, Git and Package version


On 20 Dec 2017, at 19:51, Vitor Medina Cruz <vitormc...@gmail.com> wrote:

Hello,

How are packages versions computed in Iceberg?

I am looking at the Metacello documentation at 'Deep in Pharo', it says I
can define dependencies at package level and it uses the following format
to identify versions: ; which I think is a pattern
used by Monticello, right? However, I can't figure what is the equivalent
(if any) in Iceberg.

Thanks in Advance,
Vitor


Hi Vitor,

Package versions do not have any sense on iceberg, where what has sense is
the “project” version. All packages point to a commit in repo.

This is to say, you do not load single package in iceberg but you load a
repository version (which is the commit).
That’s why you use Metacello expressions like this:

Metacello new
repository: ‘github://someuser/someproject:sometag';
baseline: ‘Blah’;
load.

and in your baselines, when you include another project you do

spec
baseline: ‘Blah’
with: [ spec repository: ‘github://someuser/someproject:sometag' ].

cheers!
Esteban


-- Forwarded message --
From: Esteban Lorenzano <esteba...@gmail.com>
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Cc:
Bcc:
Date: Thu, 21 Dec 2017 12:02:54 +0100
Subject: Re: [Pharo-users] Iceberg, Git and Package version


On 21 Dec 2017, at 11:03, Vitor Medina Cruz <vitormc...@gmail.com> wrote:

Then in a Metacello configuration should I reference the hash git commit or
a tag in a version method? For example, an extract from Deep in Pharo:

ConfigurationOfCoolToolSet>>version02: spec
> 
> spec for: #common do: [
> spec blessing: #beta.
> spec
> package: 'CoolToolSet-Core' with: 'CoolToolSet-Core-AlanJay.1';
> package: 'CoolToolSet-Tests' with: 'CoolToolSet-Tests-AlanJay.1';
> project: 'CoolBrowser default' with: '1.3';
> project: 'CoolBrowser Tests' with: '1.3’].
>

the thing is: you don’t use configurations with iceberg projects, you use
baselines.

Esteban


In this case  'CoolToolSet-Core-AlanJay.1' would be changed by
'CoolToolSet-Core-'?

On Wed, Dec 20, 2017 at 6:09 PM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> In iceberg you can specify
> - latest version when you do not specify anything
> - a version (but it should be a git tag so you should save you code
> with a tag - iceberg does not support it right now but you can do it
> with git)
> - 

[Pharo-users] Active IRC Chanel

2017-12-20 Thread Ian Ian
Hi All,

Is there an active IRC Chanel?  Read somewhere (can't remember) that there
is one labeled #pharo.  Is this true if so may I ask on which server it
resides?

Kindly in advance,