Re: [Pharo-users] Pharo Catalog Submission

[Stephane Ducasse]

Here is what cyril replied to me once

"Classic smalltalkhub"

Metacello new

smalltalkhubUser: 'KevinLanvin' project: 'MaterialDesignLite'; "Same
as: http://smalltalkhub.com/mc/KevinLanvin/MaterialDesignLite/main "

configuration: 'MaterialDesignLite';

version: #development;

load.


"Classic github"

Metacello new

githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish:
'development' "SHA/BranchName/Tag" path: 'src'; "Same as:
'github://DuneSt/MaterialDesignLite:development/src'"

baseline: 'MaterialDesignLite';

load.


"With groups"




Metacello new

githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish:
'development' path: 'src';

baseline: 'MaterialDesignLite';

loads: 'default'.


Metacello new

githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish:
'development' path: 'src';

baseline: 'MaterialDesignLite';

loads: #('default' 'colors').


"In case of conflict"

Metacello new

githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish:
'development' path: 'src';

baseline: 'MaterialDesignLite';

onWarningLog; "Option to log warning instead of raising a UI element
requiring user interaction"

onConflictUseIncoming; "Can be #onConflictUseOutgoing or #onConflict:"

load.


On Wed, Dec 27, 2017 at 5:15 AM, Evan Donahue  wrote:
> Hi,
>
> I have just finished making a BaselineOf and ConfigurationOf for submitting
> my github-based project to the Pharo catalog.
>
> If my ConfigurationOf is with my code on github (via Iceberg), what
> Metacello command should I run to test that it works correctly before
> submitting to the catalog (to fetch the ConfigurationOf and then load it)?
>
> Thanks,
> Evan

Re: [Pharo-users] Breakpoints in Pharo

[jtuc...@objektfabrik.de]

Ben,

I don't think you can compare #halt with Breakpoints. Breakpoints have 
two main advantages over halts:


 * They do not change source code, so there is no diff between a method
   version with and without this debugging aid. Helps a lot, especially
   in times when you urgenztly need to fix a bug in production code.
   There's no time to read diffs that baiscally have zero meaning
   saturday nights at 2:00 AM...
 * They cannot easily be packaged into the production/runtime image,
   because they are not part of the source code. Thus it cannot be
   "forgotten" when you deploy.
   This is not relevant in Pharo, where there is no packaging step as
   in VW or VAST, but there it really is. A halt in production code
   makes for a great monday morning when the new version was just
   shipped ;-)


So when you work on code to actually ship into users' hands, there are 
quite some good arguments for Breakpoints. There's more to them, like 
conditional Breakpoints that make debugging a bug so much easier and 
Watchpoints, but these would make my message way too long.


Of course all of the above-mentioned things can be achieved using 
appropriate handlers for #halt and add stuff to them or make #halts just 
ignored at deployment time, but these are also steps that can be 
forgotten...



Joachim


Am 27.12.17 um 00:26 schrieb Ben Coman:

Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov > wrote:


Can I expect that break points in Pharo work in the same way as in
Visual Works?
When I set a break point in Pharo (6.1 on Windows), it displays a
red dot with an exclamation mark and when I send this message to
an object, the debugger doesn't get invoked.


Sorry I'm not familiar with VisualWorks.
If I define this method (Pharo 6.1 on Linux)...
    Object >> myTest
        "Object new myTest"
        self halt.
        self inform: 'test'.

then evaluate the comment, a debugger is invoked.

If your example is different, could you explain it in more detail?

cheers -ben



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

[Pharo-users] Pharo Catalog Submission

[Evan Donahue]

Hi,

I have just finished making a BaselineOf and ConfigurationOf for submitting
my github-based project to the Pharo catalog.

If my ConfigurationOf is with my code on github (via Iceberg), what
Metacello command should I run to test that it works correctly before
submitting to the catalog (to fetch the ConfigurationOf and then load it)?

Thanks,
Evan

Re: [Pharo-users] Iceberg regex

[Holger Freyther]

> On 26. Dec 2017, at 23:02, Ian Ian  wrote:

Hey!


> 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.  

I tried to replace some of regexps with ZnUrl but some of the ssh/scp/git urls 
are not valid URIs and then tweaked it to include the port number. Maybe 
someone else has another pass it?

In PR#473[1] I mentioned git:g...@domin.com:path as a non valid URL that is 
happily accepted by git itself. :}

holger


[1] https://github.com/pharo-vcs/iceberg/pull/473

Re: [Pharo-users] Breakpoints in Pharo

[Ben Coman]

Hi Andrei,

On 26 December 2017 at 09:51, Andrei Stebakov  wrote:

> Can I expect that break points in Pharo work in the same way as in Visual
> Works?
> When I set a break point in Pharo (6.1 on Windows), it displays a red dot
> with an exclamation mark and when I send this message to an object, the
> debugger doesn't get invoked.
>

Sorry I'm not familiar with VisualWorks.
If I define this method (Pharo 6.1 on Linux)...
Object >> myTest
"Object new myTest"
self halt.
self inform: 'test'.

then evaluate the comment, a debugger is invoked.

If your example is different, could you explain it in more detail?

cheers -ben

Re: [Pharo-users] pharo 64 bits on mac os X - El Capitan

[Manuel Leuenberger]

I ran Pharo 6 64 bit on El Capitan some time ago. I am not sure about the exact 
version of Pharo and VM though. Have you tried with older VMs?

Cheers,
Manuel

> On 26 Dec 2017, at 17:22, Renaud de Villemeur  
> wrote:
> 
> Hi all 
> 
> I want to run pharo on Mac Os X. It is on old hardware, and thus, I cannot 
> upgrade to latest version of MacOsX. I am trying to run in on El Capitan - v 
> 10.11.6.
> 
> When I start pharo from the command line, I have this error:
> $ ./Pharo 
> 
> Illegal instruction Tue Dec 26 11:12:55 2017
> 
> 
> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>  $ Date: Thu Jul 20 
> 12:42:21 2017 -0700 $
> Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>  $
> 
> Abort trap: 6
> 
> I am using latest 6.1 64bit link from pharo web site.
> 
> If I am using the command line install with curl, I have the following result:
> ./pharo-ui 
> 
> Illegal instruction Tue Dec 26 11:19:49 2017
> 
> 
> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>  $ Date: Thu Jul 20 
> 12:42:21 2017 -0700 $
> Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>  $
> 
> ./pharo-ui: line 11:   991 Abort trap: 6   
> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@"
> 
> Any hint ? Or should we specify a minimal version of mac os X for 64 bit 
> version ?
> 
> Thanks in advance for your help
> Renaud
> 

Re: [Pharo-users] Object Persistence

[Manuel Leuenberger]

I’ve always liked Neo4j to persist object graphs. Also has a nice query 
language. The database is not fool-proof (isolation issues, out of memory on 
expensive queries), but works fine for analytics.

> On 25 Dec 2017, at 10:43, Ian Ian  wrote:
> 
> Hi All,
> 
> Thoughts of a purely OO nature?
> 
> :)

Re: [Pharo-users] Object Persistence

[Offray Vladimir Luna Cárdenas]

But if VOSS is GPL, that doesn't imply that, when ported, all Pharo
could become GPL, as discussed time and again in the list?

Cheers,

Offray

On 25/12/17 10:01, Stephane Ducasse wrote:
> 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  wrote:
>> Hi All,
>>
>> Thoughts of a purely OO nature?
>>
>> :)
>

Re: [Pharo-users] How to connect to DB2

[Andrei Stebakov]

Thank you for the answers! I thought ODBC was deprecated from Garage, I'll
give it another look.

On Fri, Dec 22, 2017 at 10:53 PM, Thomas Sattler 
wrote:

> I have no problem using Garage to connect to Postgres.  Don't know if it
> will work with DB2, but since it's ODBC, it should.
>
> On Fri, Dec 22, 2017 at 6:36 PM, Andrei Stebakov 
> wrote:
>
>> Hi Stef
>>
>> I already checked Garage, it doesn't have support for DB2. It used to
>> have support for odbc, but now it's deprecated.
>>
>> Andrei
>>
>> On Dec 22, 2017 15:11, "Stephane Ducasse" 
>> wrote:
>>
>>> Hi andrei
>>>
>>> I do not know the status of OBDC but you should know that code on
>>> squeaksource is in general quite old.
>>> Have a look at Garage which is a kind of JBDC.
>>>
>>> https://github.com/pharo-rdbms/garage
>>>
>>> You should probably have a version available via the catalog
>>>
>>> Stef
>>>
>>> On Fri, Dec 22, 2017 at 2:43 PM, Andrei Stebakov 
>>> wrote:
>>> > Hi Stef
>>> >
>>> > Gofer new
>>> >   squeaksource: 'ODBC';
>>> >   package: 'ConfigurationOfODBC'; load.
>>> >   (Smalltalk at: #ConfigurationOfODBC) load.
>>> >
>>> > When I execute the code above I got an exception doesNotUnderstand:
>>> > #selector in RBParser>>externalFunctionDeclaration. Looks like
>>> currentScope
>>> > variable is not defined.
>>> > Also if I install ODBC from the catalog it also fails.
>>> >
>>> > Andrei
>>> >
>>> >
>>> > On Fri, Dec 22, 2017 at 2:19 AM, Stephane Ducasse <
>>> stepharo.s...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi andrei
>>> >>
>>> >> First welcome to this list.
>>> >> Second can you explain to us what is the experience that you did so
>>> >> that you can state that ODBC is broken in Pharo 6.1?
>>> >>
>>> >> Stef
>>> >>
>>> >> On Thu, Dec 21, 2017 at 11:48 PM, Andrei Stebakov <
>>> lisper...@gmail.com>
>>> >> wrote:
>>> >> > Looks like ODBC is broken in Pharo 6.1.
>>> >> > What's the best way to get access to DB2 in Pharo?
>>> >> >
>>> >> >
>>> >>
>>> >
>>>
>>>
>

[Pharo-users] pharo 64 bits on mac os X - El Capitan

[Renaud de Villemeur]

Hi all

I want to run pharo on Mac Os X. It is on old hardware, and thus, I cannot
upgrade to latest version of MacOsX. I am trying to run in on El Capitan -
v 10.11.6.

When I start pharo from the command line, I have this error:
$ ./Pharo

Illegal instruction Tue Dec 26 11:12:55 2017


VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $
Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
$

Abort trap: 6

I am using latest 6.1 64bit link from pharo web site.

If I am using the command line install with curl, I have the following
result:
./pharo-ui

Illegal instruction Tue Dec 26 11:19:49 2017


VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $
Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
$

./pharo-ui: line 11:   991 Abort trap: 6
"$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@"

Any hint ? Or should we specify a minimal version of mac os X for 64 bit
version ?

Thanks in advance for your help
Renaud

Re: [Pharo-users] Athens error

[Pavel Krivanek]

2017-12-26 14:32 GMT+01:00 Nicolai Hess :

> Running your drgeo.image on a recent linux pharo 64 bit vm gives this
> error message first:
>
> /home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources.
>
> With pharo 7, every (bootstrapped)image needs its own sources file?
>

Every Pharo 7 build creates own sources file but this sources file can be
shared between several images based on this build. So for final Pharo 7 we
may release one sources file but I doubt that we will do it.
During bootstrap all code is loaded into the image as new code so at the
end you have empty sources file and huge changes file. We condense such
changes file and transform it into sources file so you have empty changes.
But we would like have sources directly in the image in compressed form.

-- Pavel


>
>
> 2017-12-26 11:59 GMT+01:00 Hilaire :
>
>> Just make a drgeo build with latest image as of today, the problem is the
>> same with latest image, as long as the source file is not present. Here is
>> the newest built[1]
>>
>> Hilaire
>>
>>
>> [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
>>
>> Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :
>>
>>> Hi Hilaire
>>>
>>> your P7 image is older and has problems with FreeType fonts
>>> initialization that should be fixed in the newest builds. Maybe that is
>>> cause of the Athens issues you are facing. Please upgrade.
>>>
>>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
>

[Pharo-users] Iceberg regex

[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,  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 
> To: Any question about pharo is welcome 
> 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  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" 
> To: Any question about pharo is welcome 
> Cc:
> Bcc:
> Date: Mon, 25 Dec 2017 15:16:57 -0300
> Subject: Re: [Pharo-users] Iceberg URL regex not matching how I would
> expect it to?
> u...@server.com:/proj/proj.git
>
> Isn't it: g...@server.com:user/project.git ?
>
> On Dec 24, 2017 15:36, "Ian Ian"  wrote:
>
>> 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 

Re: [Pharo-users] Thanks All.

[Stephan Eggermont]

Op 26-12-2017 om 14:03 schreef 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.


I have always found the Gemstone people very approachable, and open to 
trying out ideas.


Stephan

Re: [Pharo-users] Thanks All.

[Stephan Eggermont]

Op 26-12-2017 om 14:03 schreef 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.


I have always found the Gemstone people very approachable, and open to 
trying out ideas.


Stephan

Re: [Pharo-users] Thanks All.

[Stephan Eggermont]

Op 26-12-2017 om 14:03 schreef 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.


I have always found the Gemstone people very approachable, and open to 
trying out ideas.


Stephan

Re: [Pharo-users] Athens error

[Nicolai Hess]

Running your drgeo.image on a recent linux pharo 64 bit vm gives this error
message first:

/home/nicolai/devel/pharo/Pharo7.0-32bit-52a28a8.sources.

With pharo 7, every (bootstrapped)image needs its own sources file?


2017-12-26 11:59 GMT+01:00 Hilaire :

> Just make a drgeo build with latest image as of today, the problem is the
> same with latest image, as long as the source file is not present. Here is
> the newest built[1]
>
> Hilaire
>
>
> [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
>
> Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :
>
>> Hi Hilaire
>>
>> your P7 image is older and has problems with FreeType fonts
>> initialization that should be fixed in the newest builds. Maybe that is
>> cause of the Athens issues you are facing. Please upgrade.
>>
>>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

[Pharo-users] Thanks All.

[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,  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 
> 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 
> To: Any question about pharo is welcome 
> 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 :
> >
> > Hi All,
> >
> > Thoughts of a purely OO nature?
> >
> > :)
>
>
>
>
>
> -- Forwarded message --
> From: Torsten Bergmann 
> To: pharo-users@lists.pharo.org
> Cc: Any question about pharo is welcome 
> 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" 
> > An: "Any question about pharo is welcome" 
> > 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 :
> > >
> > > Hi All,
> > >
> > > Thoughts of a purely OO nature?
> > >
> > > :)
> >
> >
> >
>
>
>
>
> -- Forwarded message --
> From: Stephane Ducasse 
> To: Any question about pharo is welcome 
> 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  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
>
>

Re: [Pharo-users] Athens error

[Hilaire]

Just make a drgeo build with latest image as of today, the problem is 
the same with latest image, as long as the source file is not present. 
Here is the newest built[1]


Hilaire


[1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0

Le 26/12/2017 à 11:15, Pavel Krivanek a écrit :

Hi Hilaire

your P7 image is older and has problems with FreeType fonts 
initialization that should be fixed in the newest builds. Maybe that 
is cause of the Athens issues you are facing. Please upgrade.




--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Athens error

[Pavel Krivanek]

Hi Hilaire

your P7 image is older and has problems with FreeType fonts initialization
that should be fixed in the newest builds. Maybe that is cause of the
Athens issues you are facing. Please upgrade.

-- Pavel

2017-12-25 12:05 GMT+01:00 Hilaire :

> The source is really needed to get Athens functionning, otherwise there is
> an error. On top of that, the source file name is confused by Pharo (it
> should be mimic of the 32bits images, althought 64bits image is used, and
> it should not depend on the bits number I guess).
>
> Here is an archive with the image[1], go in Contents/Resources/drgeo.image
> and used a 64 bits VM to run the image, do not used the embedded VMs, there
> are for P3.
>
> [1] https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
>
> Hilaire
>
> Le 20/12/2017 à 21:08, Stephane Ducasse a écrit :
>
>> Normally the call does not need the sources (if I'm correct in the
>> past it needed to generate the correct method argument or something
>> like that).
>> Can you provide more information? or the image somewhere?
>>   Because FFI should improve and we are looking for edge corner bugs.
>>
>> Stef
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Sven Van Caekenberghe]

> On 26 Dec 2017, at 08:21, Yuriy Tymchuk  wrote:
> 
> Hi Sven,
> 
> No, I’m on Mac (OS 10.13).

That is not good then, Uko, but again, there is no way to start debugging this 
without a reliable test case that I can run too.

Sven

> Cheers.
> Uko
> 
>> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe  wrote:
>> 
>> 
>> 
>>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  wrote:
>>> 
>>> 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.
>> 
>> You are on Windows I guess ?
>> 
>>> Cheers,
>>> Uko
>>> 
 On 25 Dec 2017, at 05:42, Andrew Glynn  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" 
  
 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/1028d66426293e821ecfd9ef1a0731df/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/1028d66426293e821ecfd9ef1a0731df/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
 
 
 
 
>>> 
>>> 
>> 
>> 
> 
>