[Pharo-users] Pharo Catalog tags

[Johan Brichau]

Hi,

Does anyone know why Grease does not show ‘Pharo6’ tag in the Pharo catalog 
browser?
Seaside3 does… 

I don’t know what needs to be done for that..

cheers
Johan

Re: [Pharo-users] Pharo Seaside RESTful services pragma question

[Johan Brichau]

The Seaside book REST chapter should be deprecated or changed.

Take a look here for the updated info: 
https://github.com/SeasideSt/Seaside/wiki/Seaside-REST 


Johan

> On 30 Jul 2017, at 01:46, Greg Hutchinson  
> wrote:
> 
> That worked - thanks very much.
> 
> On 29 July 2017 at 16:13, Esteban A. Maringolo  > wrote:
> Did you try setting the pragma  in the list method?
> Esteban A. Maringolo
> 
> 
> 2017-07-28 18:40 GMT-03:00 Greg Hutchinson  >:
> > I am new to Pharo/Seaside and it has been a long time since I have used
> > Smalltalk. I am trying to make a RESTful service and can’t get the pragmas
> > to work the way I think it should. (This might be the problem already).
> >
> >
> >
> >  Ie Here is my list method within class TeamMembers which is a direct
> > subclass of WARestfulHandler.
> >
> > list
> >
> >
> >
> >   ^ String streamContents: [ :stream |
> >
> >self teamMembers do: [ :each |
> >
> >stream nextPutAll: each ; crlf ]
> >
> >]
> >
> >
> >
> > and
> >
> >
> >
> > listJson
> >
> > 
> >
> > 
> >
> >
> >
> >^ (Array streamContents: [ :stream |
> >
> >   self teamMembers do: [ :each |
> >
> >  stream nextPut: (Dictionary new
> >
> > at: 'name' put: each ;
> >
> > yourself) ] ])
> >
> >   asJavascript
> >
> >
> >
> >
> >
> >
> >
> > After doing all the proper registration WAAdmin register: TeamMembers at:
> > 'team-members' when I execute in the browser
> > (http://localhost:8080/team-members ) I 
> > received the message
> >
> > /team-members not found
> > but if I execute (http://localhost:8080/team-members/list 
> > ), it brings back
> > the team member list. (However, I didn’t think I would have to add /list to
> > the URL).
> >
> >
> >
> > This seems to contradict the documentation in
> > http://book.seaside.st/book/advanced/restful/getting-started/define-handler 
> > .
> >
> >
> >
> >
> >
> > However, If I override the TeamMembers>>
> >
> > createRoutes
> >
> > | route pType|
> >
> > pType := WAFullMimeTypeMatch main:'text' sub: 'json' .
> >
> > route := WASimpleRoute method: 'GET' selector: #listJson
> > produces: pType consumes: WAWildcardMimeTypeMatch new.
> >
> > ^ OrderedCollection new
> >
> > "GET"
> >
> > add: route;
> >
> > add: (WARoute get: #list);
> >
> > yourself.
> >
> >
> >
> > Then I get the expected behaviour when I browse to
> > (http://localhost:8080/team-members ) 
> > and using curl. (ie.
> >
> > curl -H "Accept: text/json" http://localhost:8080/team-members 
> > 
> >
> > to get the Json response.
> >
> >
> >
> > When I debug the difference in the routes, it looks like using the pragmas,
> > I get WAComplexRoute(s) but of course in the overridden method createRoutes,
> > I get WASimpleRoutes.
> >
> >
> >
> > Is this the way it is supposed to work?
> >
> >
> >
> >
> >
> > Thanks in advance for any hints.
> >
> 
> 
> 
> 
> -- 
> 

[Pharo-users] Grease for Pharo7: TBehavior extensions?

[Johan Brichau]

Hi Pharoers,

We have one failing test for Grease in Pharo7.
The reason is that Grease extends the TBehavior trait with a method #fullName.

I notice this trait is no longer used? Are we supposed to extend Behavior 
directly?
Overall: what are the plans?

Some advice would be good so I can keep Grease into shape.

thanks everyone
Johan

[Pharo-users] pharo 6.1 64bit segmentation fault on linux

[Johan Brichau]

Hi,

I’m also hitting this issue: 
https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-code-into-a-64-bits-Pharo-6-1-Linux
 

Also reported here: 
http://forum.world.st/Pharo-6-1-64-bits-segmentation-fault-loading-code-on-Linux-td5034346.html
 


This stops us from using Travis-CI because the OSX builds are just way too slow 
there.

Since more recent vms are working (see thread), any chance the vm for linux is 
updated on the pharo site so we can use Smalltalk-CI?

thx for an update
Johan

Re: [Pharo-users] pharo 6.1 64bit segmentation fault on linux

[Johan Brichau]

Hi,

I’m still hitting this.
Segfault *every time* when I try to build our project using Travis-CI in Linux.

Even when I try to use the latest vm

Nobody else hits this issue??

Johan

> On 23 Dec 2017, at 01:14, Cyril Ferlicot D.  wrote:
> 
> On 12/22/2017 10:33 PM, Johan Brichau wrote:
>> Hi,
>> 
>> I’m also hitting this
>> issue: 
>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-code-into-a-64-bits-Pharo-6-1-Linux
>> Also reported
>> here: 
>> http://forum.world.st/Pharo-6-1-64-bits-segmentation-fault-loading-code-on-Linux-td5034346.html
>> 
>> This stops us from using Travis-CI because the OSX builds are just way
>> too slow there.
>> 
>> Since more recent vms are working (see thread), any chance the vm for
>> linux is updated on the pharo site so we can use Smalltalk-CI?
>> 
> 
> Hi Johan,
> 
> I think there was some work to re-establish the vm distribution done
> these days. See the result here:
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/176
> 
> I hope this will help with the publication of a new stable VM. It is
> also important for us at Synectique. To be able to have a 64bits linux
> applications reliable would help us a lot in the simplifications of our
> processes. :)
> 
> I guess that it will still have to wait some time since it's the end of
> the year and there must be a lot of people taking holidays.
> 
>> thx for an update
>> Johan
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

[Johan Brichau]

Hi,

The Seaside-Gettext package is in the Seaside repository 
http://www.smalltalkhub.com/#!/~Seaside/Seaside30Addons
The package in the PharoExtras repository is a relic.

The ConfigurationOfSeaside3 correctly references the Seaside-Gettext package 
and it’s absolutely functional (using this in production systems).

What is a bit silly is that the ConfigurationOfSeaside3 relies on people 
chosing the appropriate groups to load and the Pharo configuration browser 
always loads the default transparantly.
I will probably update that for Seaside 3.2.0, so that the default loads 
everything for newcomers, but for the current version some load configurations 
might rely on it and that’s the way it is.

Johan

On 08 Sep 2014, at 11:16, Hilaire  wrote:

> What is the purpose of the seaside-gettext package ?
> Is it a relic or is it useful? Gettext is orthogonal to Seaside.
> 
> Hilaire
> 
> Le 07/09/2014 15:32, Peter Schorsch a écrit :
>> But then I had to realize that the seaside-gettext package was not
>> installed; and also no gettext package. I found a gettext package in
>> the repositoryhttp://smalltalkhub.com/mc/PharoExtras/Gettext.
>> 
>> I installed the package ConfigurationOfGettext, but the
>> configuraitonof-browser does not show it. So I installed the package
>> Gettext via monticello.
> 
> 
> -- 
> Dr. Geo - http://drgeo.eu
> iStoa - http://istao.drgeo.eu
> 
> 

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

[Johan Brichau]

On 13 Sep 2014, at 10:09, stepharo  wrote:

>   Then what is the seaside-Getext? Is is a superset of 
> pharoExtras-gettext?

https://code.google.com/p/seaside/wiki/Gettext

In short: it’s a Seaside extension to internationalise your web app.

>   For application not doing web, does it make sense to use it?

No, but I don’t see how you guys complain about that. The package is in the 
Seaside repo and in the ConfigurationOfSeaside3.
Can you explain the issue?

>   Is it packaged separately?

yes.

Johan

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

[Johan Brichau]

On 13 Sep 2014, at 19:54, stepharo  wrote:

> 
> On 13/9/14 15:57, Hilaire wrote:
>> Hello,
>> 
>> I guess the gettext package on the seaside repo depends on the gettext 
>> package at PharoExtra and it adds some glue code for Seaside use. Is it 
>> correct?
> 
> I did not check but I think so

Yes, Seaside-Gettext an extension of Gettext for Seaside apps.

Johan

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

[Johan Brichau]

Peter,

Gettext works. See DrGeo, for example.
Also, the Seaside-Gettext extension works just fine.

If I understand correctly, the Pharo IDE (and rest of the system) has not been 
working with ant localization implementation.

Johan

On 14 Sep 2014, at 16:18, Peter Schorsch  wrote:

>> Localization is very basic functionality that should be provided by
>> the platform itself. We are in the situation that we are in only
>> because people see Pharo as something “to build on top”.
>> 
>> This way everyone does their own I18N stuff, while the right thing
>> would be to have *one* that is good and part or Pharo itself.
>> 
>> Just think about it: Pharo itself should have translated menus. So we
>> need *something* in the system anyway. Why then not make it good and
>> make it the one that everyone is using?
> 
> As a beginner with pharo I TOTALLY agree with that statement. E.g. so
> far I understood there are 3 different localization existing:
> 
>   * System internal localization 
> - never seen before, never read about before
>   * Gettext
> - does not work
>   * QCMagritte
> - shall work, did not managed it by myself. Only uses csv
>   table if I understood correctly.
> 
> Here is my suggestion (keep in mind that I did not fully understood
> QCMagritte atm). My wish is a localization that:
> 
>   * supports the gettext format for in and output
>   * has fallback options if a phrase is not translated
>   * pharo internal interface maybe a Dictionary
>   * support of different number formats (e.g. date etc.)
>   * does NOT depend on the env locales - only the IDE of pharo
> 
> Honestly, I am surprised that pharo does not work fully with utf8
> (see MathOntology discussion) and has no well documentated and working
> localization.
> 
> If I understood something wrong please correct me - I still want to
> learn pharo and seaside :)
> 

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

[Johan Brichau]

On 14 Sep 2014, at 12:59, Marcus Denker  wrote:

> Just think about it: Pharo itself should have translated menus. So we need 
> *something* in the system anyway.
> Why then not make it good and make it the one that everyone is using?

Yes, and actually, Gettext is just about the support for the Gettext format [1].
So, you can see it as an extension of the existing Localization system that is 
already in the image and it’s probably a good idea to internalize it completely.

The LocaleID and NaturalLanguageTranslator classes in the package are the same 
(and more) as those already in the image. So, why not just internalize it?
I think there are a couple of people who are willing to maintain it: Hilaire, 
Usman and myself (who are the current maintainers of the package). Maybe this 
discussion should move to pharo-dev ?

There’s not so much to the Gettext package actually. It just deserves a bit of 
a cleaning.
The hard part is: make your applications use the localization and create 
translation files…

Johan

[1] http://www.gnu.org/software/gettext/

Re: [Pharo-users] [ANN] Easy I18N for Pharo

[Johan Brichau]

On 15 Sep 2014, at 12:27, p...@highoctane.be wrote:

> With a .po bridge to/from I18N, wouldn't we have a pretty nice solution?

That is exactly what Gettext does. Once the translation dictionary is loaded 
into Pharo, it’s just string mapping.

How strings are translated (i.e. sending #translate or doing whatever) could be 
factored out. The Gettext template generator is a metaprogram that extracts the 
strings from your source code, and that could be parameterized. 

A question: without looking at the code of i18n, I notice the assumption that 
each ‘UI string’ is identified by a symbol. Is that correct or just how the 
example is presented?
In most cases, you construct ‘UI strings’ in your code as follows:

‘The user {name} clicked on item {number}’ translatedWith: { name -> self 
username . number -> self number }

So, I don’t know if i18n relies on the keys being symbols or not, but this kind 
of thing works with the Gettext translators. Normally, this should not be an 
issue since it just means using strings as the keys in the translation 
dictionaries. But it struck me because for a translator (i.e. a human) who just 
gets the thousand strings to translate, being able to translate this kind of 
sentences (instead of symbols) is essential.

I also agree 100% with Hilaire: Gettext is a standard where plenty of external 
tools can work with. Though it’s nice to have translation tools in the image, 
you will have to do everything yourself. Just take a look at everyhting that is 
done by poedit [1]. Do we really want to implement everything ourselves?

[1] http://poedit.net/

Johan


> 
> Phil
> 
> On Mon, Sep 15, 2014 at 11:35 AM, Hilaire  wrote:
> 
> Nice for project with a delimited scope.
> Problem: you cut yourself from translators aggregated in oneline free 
> software community. For example https://translations.launchpad.net/drgeo
> For DrGeo this is a show stopper.
> 
> Hilaire
> 
> Le 15/09/2014 10:23, Torsten Bergmann a écrit :
> Need an easy translation framework for your Pharo application
> with no external dependency?
> 
> Then check out the I18N project:
> 
>http://smalltalkhub.com/#!/~TorstenBergmann/I18N
> 
> Docu and examples can be found on the same page, screenshot
> is attached.
> 
> Bye
> T.
> 
> 
> 
> -- 
> Dr. Geo - http://drgeo.eu
> iStoa - http://istao.drgeo.eu
> 
> 
> 
> 

Re: [Pharo-users] [ANN] Easy I18N for Pharo

[Johan Brichau]

On 15 Sep 2014, at 19:31, Stephan Eggermont  wrote:

> The main problems I have with external tools is the lack of translation 
> context and the
> slow feedback cycle. That is killing for translation speed and quality.


I can understand that in-app tools work well for developers but when you start 
working with translators (humans) that are not developers (and certainly not 
Smalltalkers), you want to export the translation work. Now, Gettext is 
certainly not the walhalla, but I see a lot of things to do in-app before even 
getting to the level of those external tools.

Also, there is translation context exported to Gettext (but this does not help 
actually) and whenever a translator changes the file, we immediately read it 
again in the app, so I don’t really understand the slow feedback cycle issue.

There are other tools btw:
- http://translate-toolkit.readthedocs.org/en/latest/index.html
- http://www.arizona-software.ch/ilocalize/

I’m all for an approach where Pharo explicitly caters for multiple possible 
translators, where Gettext would just be one possible option. This is more or 
less what exists today, except that it’s ad-hoc and deserves a cleaned 
implementation and design. Gettext and other translators can plugin to the 
Locale and Translator class hierarchies that are there.

Johan

Re: [Pharo-users] [ANN] Easy I18N for Pharo

[Johan Brichau]

On 15 Sep 2014, at 23:18, Torsten Bergmann  wrote:

> I just refer to my original announcement: "Need an EASY translation 
> framework for your Pharo application with NO EXTERNAL dependency?”

Hi Torsten,

Agree with you 100% and that’s also how I understood your announcement of i18n.

>  so let the users decide what
> he wants to use.

exactly

> 1. Why is "GetText" not easily loadable from the config browser? If we
>want people to find and use it we should make it accessible.

The ConfigurationOfGettext exists but I don’t have access to the metarepo.

> 2. When you google for "Pharo" and "GetText" you will find 
>https://code.google.com/p/seaside/wiki/Gettext as the first match.
> 
>The page is outdated, points to the old repository on SqueakSource 
>http://www.squeaksource.com/PharoNonCorePackages/ and even that
>page does not include a hint that meanwhile the package moved to STHub.

Point taken. I will move the page to the Seaside book.

> 3. Also the new hosting on the STHub page 
> http://smalltalkhub.com/#!/~PharoExtras/Gettext 
>seems broken, it includes the following comment:
> 
>  "Migrated from PharoNonCorePackages. Should be adapted to Pharo2.0"
> 
> Outdated comment or not usable in Pharo 3.0/4.0?

Outdated comment. I updated it.

> 4. The last version there is Gettext-HilaireFernandes.33, that is the one 
> that is
>also included in Dr. Geo. The code should be updated as
> 
>  a) it includes a reference to missing class "MethodReference" in 
> #appendVocabulary:domains: 
>  b) the  NaturalLanguageTranslator>>cleanUp method references a class 
> variable that is not there
> 
>Any takers?

Allright, as I have been mostly using the Seaside extension to it, this are 
parts I have not used.
Ok, will take a look at them since I’m working in this area concerning the 
gemstone port as well.

> 5. Writing a simple docu for I18N on STHub took me only a few minutes using 
> markdown and 
>https://stackedit.io. (Pillar and PillarHub provide the same, but STHub 
> does not support it).
> 
>So why not write a similar docu for GetText including code snippets and 
> all the knowledge that 
>seems to be there already from using it...

Ha, a bit optimistic there… I don’t write a page of text in a couple of 
minutes, but I know what you mean ;)

cheers
Johan

Re: [Pharo-users] Seaside - How do I install Scriptaculous on a clean Seaside install (via Configuration Browser) on Pharo?

[Johan Brichau]

Hi Mircea,

Pharo’s Configuration browser loads the default group of the Metacello 
configuration, which unfortunately was set to ‘Core’ for Seaside 3.1.
So, you will need to load additional groups programmatically:

(ConfigurationOfSeaside3 project version: #stable) load: #(‘Scriptaculous’ 
‘JSON’)

If you want to get the list of possible groups to load, inspect:

(ConfigurationOfSeaside3 project version: #stable) groups

This is something we fixed for Seaside 3.2, where the default will load 
everything to help newcomers. 
We prefer not to change the existing 3.1 configuration versions to not break 
existing uses, but it’s fixed in the upcoming version.

Btw, Scriptaculous is really outdated. You will prefer to use jQuery and 
jQuery-UI (or any other JS framework…)

cheers
Johan

> On 31 Jan 2015, at 15:01, Mircea S.  wrote:
> 
> I used the method described here to install Seaside3 on Pharo. All is well, 
> but Scriptaculous doesn't come preinstalled. How do I get it?
> 
> Seaside3 :
> 
> 1: Go to the configuration manager
> 
> 2: Select the Seaside 3 configuration. Click on Install.
> 
> 3: Wait while it loads. Takes a couple of minutes on an i7 and a decent 
> network link.
> 
> 4: Open a Workspace and start a ZincServerAdaptor on the port you like (here 
> 8080): ZnZincServerAdaptor startOn: 8080. (then CMD+d for Do It)
> 
> 7: Access Seaside from your browser.
> 
> 8: Install Scriptaculous, but how?

Re: [Pharo-users] Seaside - How do I install Scriptaculous on a clean Seaside install (via Configuration Browser) on Pharo?

[Johan Brichau]

You _can_ use Gofer to load individual packages, but the point of the Metacello 
configuration is that it will install the dependencies for you.
So, it’s not a good idea to load them individually, unless you want to end up 
missing some prerequisite packages.

Johan

> On 31 Jan 2015, at 20:06, Mircea S.  wrote:
> 
> For those looking to install jQuery into Seaside can use these:
> 
> Gofer new url:'http://www.smalltalkhub.com/mc/Seaside/Seaside31/main' 
> <http://www.smalltalkhub.com/mc/Seaside/Seaside31/main'>; package: 
> 'Javascript-Core'; load. 
> Gofer new url:'http://www.smalltalkhub.com/mc/Seaside/Seaside31/main' 
> <http://www.smalltalkhub.com/mc/Seaside/Seaside31/main'>; package: 
> 'JQuery-Core'; load. 
> Gofer new url:'http://www.smalltalkhub.com/mc/Seaside/Seaside31/main' 
> <http://www.smalltalkhub.com/mc/Seaside/Seaside31/main'>; package: 
> 'JQuery-UI'; load.
> "notice that there is no -Core on this last one, I don't know why"
> 
> 
> 
> Pe 31 ian. 2015, la 16:23, Johan Brichau  <mailto:jo...@inceptive.be>> a scris:
> 
>> Hi Mircea,
>> 
>> Pharo’s Configuration browser loads the default group of the Metacello 
>> configuration, which unfortunately was set to ‘Core’ for Seaside 3.1.
>> So, you will need to load additional groups programmatically:
>> 
>> (ConfigurationOfSeaside3 project version: #stable) load: #(‘Scriptaculous’ 
>> ‘JSON’)
>> 
>> If you want to get the list of possible groups to load, inspect:
>> 
>> (ConfigurationOfSeaside3 project version: #stable) groups
>> 
>> This is something we fixed for Seaside 3.2, where the default will load 
>> everything to help newcomers. 
>> We prefer not to change the existing 3.1 configuration versions to not break 
>> existing uses, but it’s fixed in the upcoming version.
>> 
>> Btw, Scriptaculous is really outdated. You will prefer to use jQuery and 
>> jQuery-UI (or any other JS framework…)
>> 
>> cheers
>> Johan
>> 
>>> On 31 Jan 2015, at 15:01, Mircea S. >> <mailto:mir...@unom.ro>> wrote:
>>> 
>>> I used the method described here to install Seaside3 on Pharo. All is well, 
>>> but Scriptaculous doesn't come preinstalled. How do I get it?
>>> 
>>> Seaside3 :
>>> 
>>> 1: Go to the configuration manager
>>> 
>>> 2: Select the Seaside 3 configuration. Click on Install.
>>> 
>>> 3: Wait while it loads. Takes a couple of minutes on an i7 and a decent 
>>> network link.
>>> 
>>> 4: Open a Workspace and start a ZincServerAdaptor on the port you like 
>>> (here 8080): ZnZincServerAdaptor startOn: 8080. (then CMD+d for Do It)
>>> 
>>> 7: Access Seaside from your browser.
>>> 
>>> 8: Install Scriptaculous, but how?
>> 
>> 

Re: [Pharo-users] Seaside jQuery - Sorting a list with drag and drop and sending it back via Ajax causes OrderedCollection to turn into an Array?

[Johan Brichau]

> On 27 Feb 2015, at 09:45, Serge Stinckwich  wrote:
> 
> You can contribute here:
> https://github.com/SquareBracketAssociates/DynamicWebDevelopmentWithSeaside 
> 
Not really.
The transfer of the book from Pier to Pillar is ‘in process’ and a bit 
‘stalled’ because of an issue in Pillar.

For now, if you can package your code and send it to the mailinglist, I can 
archive it and someone can pick it up when going through the book.

Johan

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

[Johan Brichau]

This sounds familiar to what we reported a while back: 
http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html
 


Unfortunately, we did not investigate any further. Instead, we work around the 
bug by just retrying the connection on this failure as it always works on a 
second try.

Johan

> On 27 Feb 2015, at 23:36, Sven Van Caekenberghe  wrote:
> 
> 
>> On 27 Feb 2015, at 21:18, Sabine Manaa  wrote:
>> 
>> Hi Sven,
>> 
>> thank you for your hints.
>> 
>> Indeed, the variable @in of ZdcSecureSocketStream has the string  
>> "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 
>> variable.
> 
> That is normal: the in buffer contains encrypted binary data, the out buffer 
> will contain the cleartext (but still in binary).
> 
>> Can you tell me, what to add to the pharo code that the encoding is 
>> correct/so that is equal to the curl command?
> 
> I don't think there is an encoding problem: the charset is set to utf-8 which 
> will be picked up. Besides, the returned content is plain ascii anyway.
> 
> The issue is probably the Connection:close and the missing Content-Length. 
> This means that the HTTPS stream has to be read until the end. I have seen 
> this fail in the past in rare cases.
> 
> Are you on Windows ?
> 
> Could you try on Linux ?
> 
>> comparison of headers: they seem to be equal, also the content type is in 
>> both cases 'application/json;charset=UTF-8'
>> The ZnResponse headers:
>> a ZnHeaders(
>> same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 
>> 'no-store')
>> same 'Connection'->'close' 
>> same 'Content-Type'->'application/json;charset=UTF-8' 
>> same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' 
>> same 'Expires'->'0' 
>> same 'Pragma'->#('no-cache' 'no-cache') 
>> same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/' 
>> same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' 
>> same 'X-Application-Context'->'0.3:8080' 
>> same 'X-Content-Type-Options'->'nosniff' 
>> same 'X-Frame-Options'->'DENY' 
>> same 'X-Xss-Protection'->'1; mode=block' )
>> 
>> result of curl command at command line
>> < HTTP/1.1 200 OK
>> same < Date: Fri, 27 Feb 2015 17:58:37 GMT
>> same < X-Content-Type-Options: nosniff
>> same < X-XSS-Protection: 1; mode=block
>> same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
>> same < Pragma: no-cache
>> same < Expires: 0
>> same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains
>> same < X-Frame-Options: DENY
>> same < X-Application-Context: 0.3:8080
>> < Cache-Control: no-store
>> < Pragma: no-cache
>> same < Content-Type: application/json;charset=UTF-8
>> same < Connection: close
>> same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/
>> 
>> regards 
>> sabine
>> 
>> 2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden 
>> email]>:
>> Sabine, 
>> 
>>> On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote: 
>>> 
>>> Hi Sven, 
>>> Hi all, 
>>> 
>>> I try to send a curl command (which works at command line) from Pharo. 
>>> I get the error: "SSL Exception: decrypt failed code:5" 
>>> 
>>> The working command line command is: 
>>> 
>>> curl -v  -H 'Accept: application/json' -u 'aUser:aPassword' 
>>> 'https://user.xxx.net/oauth/token?grant_type=client_credentials'
>>> 
>>> the result is something like: 
>>> {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"}
>>>  
>>> 
>>> My current Pharo code is: 
>>>   | theZnClient | 
>>>   theZnClient := ZnClient new 
>>>   systemPolicy ; 
>>>   https; 
>>>   host: 'user.xxx.net'; 
>>>   path: 'oauth/token?grant_type=client_credentials'; 
>>>   username: 'aUser' password: 'aPassword'; 
>>>   accept: ZnMimeType applicationJson; 
>>>   get. 
>>>   theZnClient inspect close. 
>>> 
>>> 'aPassword' and 'aUser' and xxx.net was replaced by me for security 
>>> reasons. 
>>> 
>>> In Pharo, I get a walkback with the error message 
>>> 'SSL Exception: decrypt failed [code:-5]' 
>>> 
>>> But I see, that the ZdcSecureSocketStream has the correct result 
>>> ({"access_token":...":"write"}) in its collection attribute at 
>>> utf-8 string and at latin1-string 
>>> 
>>> so, the request is done and the result is available but then it fails here: 
>>> ZdcSecureSocketStream(Object)>>error: 
>>> ZdcSecureSocketStream>>sslException:code: 
>>> ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... 
>>> ZdcSecureSocketStream>>fillBytes:startingAt:count: 
>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait 
>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer 
>>> ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:s

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

[Johan Brichau]

Hi Sabine,

I took a closer look and indeed, that strategy probably only works in our 
usecase where it’s a download of a zip tarball from github that fails in the 
Metacello code.
Because on the second try, the github cache was already created, Metacello no 
longer sends the request to github and we pass by it.

So, our ‘workaround’ does not apply outside of downloading from github. 

It does seem to be the same problem though. The SSL plugin is reporting an 
error while the connection closed just fine.
If that’s the case, the culprit is the SSL plugin… 

Johan

> On 28 Feb 2015, at 10:44, Sabine Manaa  wrote:
> 
> Hi Johan,
> 
> I tried this: I put an exception handler around and on error, I tried again, 
> but the error still occurs.
> 
> Regards
> Sabine
> 
> 2015-02-28 8:54 GMT+01:00 Johan Brichau-2 [via Smalltalk] <[hidden email] 
> >:
> This sounds familiar to what we reported a while back: 
> http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html
>  
> <http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html>
> 
> Unfortunately, we did not investigate any further. Instead, we work around 
> the bug by just retrying the connection on this failure as it always works on 
> a second try.
> 
> Johan
> 
>> On 27 Feb 2015, at 23:36, Sven Van Caekenberghe <[hidden email] 
>> <http://user/SendEmail.jtp?type=node&node=4808485&i=0>> wrote:
>> 
>> 
>>> On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email] 
>>> <http://user/SendEmail.jtp?type=node&node=4808485&i=1>> wrote:
>>> 
>>> Hi Sven,
>>> 
>>> thank you for your hints.
>>> 
>>> Indeed, the variable @in of ZdcSecureSocketStream has the string  
>>> "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 
>>> variable.
>> 
>> That is normal: the in buffer contains encrypted binary data, the out buffer 
>> will contain the cleartext (but still in binary).
>> 
>>> Can you tell me, what to add to the pharo code that the encoding is 
>>> correct/so that is equal to the curl command?
>> 
>> I don't think there is an encoding problem: the charset is set to utf-8 
>> which will be picked up. Besides, the returned content is plain ascii anyway.
>> 
>> The issue is probably the Connection:close and the missing Content-Length. 
>> This means that the HTTPS stream has to be read until the end. I have seen 
>> this fail in the past in rare cases.
>> 
>> Are you on Windows ?
>> 
>> Could you try on Linux ?
>> 
>>> comparison of headers: they seem to be equal, also the content type is in 
>>> both cases 'application/json;charset=UTF-8'
>>> The ZnResponse headers:
>>> a ZnHeaders(
>>> same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 
>>> 'no-store')
>>> same 'Connection'->'close' 
>>> same 'Content-Type'->'application/json;charset=UTF-8' 
>>> same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' 
>>> same 'Expires'->'0' 
>>> same 'Pragma'->#('no-cache' 'no-cache') 
>>> same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net 
>>> <http://prod.gini.net/>; path=/' 
>>> same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' 
>>> same 'X-Application-Context'->'0.3:8080' 
>>> same 'X-Content-Type-Options'->'nosniff' 
>>> same 'X-Frame-Options'->'DENY' 
>>> same 'X-Xss-Protection'->'1; mode=block' )
>>> 
>>> result of curl command at command line
>>> < HTTP/1.1 200 OK
>>> same < Date: Fri, 27 Feb 2015 17:58:37 GMT
>>> same < X-Content-Type-Options: nosniff
>>> same < X-XSS-Protection: 1; mode=block
>>> same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
>>> same < Pragma: no-cache
>>> same < Expires: 0
>>> same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains
>>> same < X-Frame-Options: DENY
>>> same < X-Application-Context: 0.3:8080
>>> < Cache-Control: no-store
>>> < Pragma: no-cache
>>> same < Content-Type: application/json;charset=UTF-8
>>> same < Connect

Re: [Pharo-users] ZnClient and percent characters

[Johan Brichau]

Hi,

first off, I found this article a good read on the topic:
http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding
 


> One thing which has not been looked at in this discussion is why Jimmie's 
> first attempt to solve the problem failed. He replaced every comma in the 
> query by its percent encoding, '%2C'. This failed because ZnClient replaced 
> this by '%252C', i.e. it percent encoded the percent sign. In my first 
> attempt to help him, I tried replacing the query line by:
>  queryAt: 'fields' put: 'displayName,instrument,pip' urlEncoded;
> but this produced the same result. The puzzling thing is why ZnClient is 
> doing this. 

This is because the #queryAt:put: method accept non-url-encoded strings.
The application is not responsible for encoding the URL, Zinc is.
How could I otherwise ever send a string with a percent character via a url ?

> In http://www.w3.org/Addressing/URL/uri-spec.html it is stated that:
> " The percent sign ("%", ASCII 25 hex) is used as the escape character in the 
> encoding scheme and is never allowed for anything else."
> Further on, there are two examples of strings which are illegal as URIs 
> because they contain percent signs which are not followed by two decodable 
> hex characters. Hence, if ZnClient encounters a percent sign in a query 
> string, either it is the beginning of a percent encoded character or it is 
> illegal.

This is true when Zn is parsing a URL, not when it’s accepting parts to 
construct the URL (like when you’re using the #queryAt:put: methods).

cheers
Johan

Re: [Pharo-users] ZnClient and percent characters

[Johan Brichau]

Hi all, Sven,

I think what many people need is to have a ZnClient subclass that follows the 
‘better safe than sorry’ approach.
In this way, there is an easy escape when someone bumps into a server that is 
not strictly implementing the standard.

We bumped into this too with the + character when upgrading from an earlier 
version of Zinc. In particular, a lightweight Java http server we were 
communicating with was excepting the + character to be encoded in the path, 
although it should not. 

Just off the top of my head, this seems quite easy to do as all the 
abstractions are present in Zinc to achieve this, no?

But I do support that Zinc is teaching us to behave according to the standard 
(although the standard is crap :)

cheers,
Johan 

> On 11 Jun 2015, at 00:56, Norbert Hartl  wrote:
> 
> Just to clarify:
> 
> "Characters in the "reserved" set are not reserved in all contexts.
>The set of characters actually reserved within any given URI
>component is defined by that component. In general, a character is
>reserved if the semantics of the URI changes if the character is
>replaced with its escaped US-ASCII encoding."
> If I were you I'd subclass ZnUrl and implement 
> #encodeQuery:on:
> on that class. You could have an extension method in ZnResourceMetaUtils that 
> returns the character set you need to have encoded. In ZnClient you just set 
> your ZnUrl derived class object as #url:
> Cannot think of anything better for a quick resolve of your problem.
> Norbert
>> Am 11.06.2015 um 00:26 schrieb Jimmie Houchin > >:
>> 
>> I am not an expert on URIs or encoding. However, this is a requirement of 
>> the API I am using and I am required to submit an encoded URI with %2C and 
>> no commas.
>> 
>> As far as commas needing to be escaped, it seems from other sources that 
>> they should be.
>> 
>> From https://www.ietf.org/rfc/rfc2396.txt 
>> 
>> The plus "+", dollar "$", and comma "," characters have been added to
>>those in the "reserved" set, since they are treated as reserved
>>within the query component.
>> 
>> States that commas are reserved within the query component.
>> 
>> http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded 
>> 
>> 
>> Regardless of what is or is not required, I do need the ability to have a 
>> query string with commas encoded as %2C in order to satisfy and use the API 
>> which states.
>> 
>> fields: Optional An URL encoded (%2C) comma separated list of instrument 
>> fields that are to be returned in the response. The instrument field will be 
>> returned regardless of the input to this query parameter. Please see the 
>> Response Parameters section below for a list of valid values.
>> 
>> Which will look like this or something similar.
>> 
>> fields=displayName%2Cinstrument%2Cpip
>> 
>> 
>> Thanks.
>> 
>> Jimmie
>> 
>> On 06/10/2015 03:27 PM, Norbert Hartl wrote:
>>> That's because the comma does not need to be escaped in the query part of 
>>> the uri.
>>> 
>>> Norbert
>>> 
 Am 10.06.2015 um 22:00 schrieb Jimmie Houchin  
 :
 
 On 06/10/2015 10:32 AM, Sven Van Caekenberghe wrote:
>> On 10 Jun 2015, at 17:24, David  
>>  wrote:
>> 
>> El Wed, 10 Jun 2015 10:14:37 -0500
>> Jimmie Houchin  
>> escribió:
>>> Hello,
>>> 
>>> I am attempting to use ZnClient to request data. The request requires
>>> a %2C (comma) delimited string as part of the query. Below is a
>>> snippet.
>>> 
>>> znClient
>>> addPath: '/v1/instruments';
>>> queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip';
>>> get ;
>>> contents)
>>> 
>>> The string  'displayName%2Cinstrument%2Cpip'
>>> is being converted to  'displayName%252Cinstrument%252Cpip'
>>> which causes the request to fail.
>>> 
>>> The query needs to be
>>> fields=displayName%2Cinstrument%2Cpip
>>> 
>>> I have not found how to do this correctly.
>>> Any help greatly appreciated.
>>> 
>>> Thanks.
>>> 
>>> Jimmie
>>> 
>>> 
>> Maybe a silly thing, but since %2C = , ... Did you tried already to
>> make itself encode that? Like
>> znClient
>>  addPath: '/v1/instruments';
>>  queryAt: 'fields' putAll: 'displayName,instrument,pip';
>>  get ;
>>  contents)
>> 
>> I suspect it is using encoding internally, that is why % is also
>> encoded if you try to put it.
>> 
>> I hope that works
> Not silly and no need to suspect, but absolutely correct !
> 
> Sven
 My apologies for not having full disclosure.
 
 Pharo 4, new image, freshly installed Zinc stable version.
 Xubuntu 15.04
 
 
 
 That 

[Pharo-users] Pharo on retina macbook

[Johan Brichau]

Hi,

I just started using a Macbook pro with retina display.
I notice the fonts are quite blurry. Is there something one can do to improve 
that?

Johan

Re: [Pharo-users] Pharo on retina macbook

[Johan Brichau]

Hi again,

> This should be a known issue as it was raised before. The problem occurs with 
> any font. It has to do with the VM as far as I understood. I am not sure what 
> is needed to be done, though.

I know this was raised when the retina display came out but I did not follow 
any development since I was not using one.
Now, I thought it had been fixed because, surely, I must not be the only one 
using a retina macbook with Pharo? 

Anyway, I can understand if this is a known issue but is it well understood 
what should be done?

> What version of Pharo?
30856

> What version of OSX?
10.9.4

> What fonts?
Any font that I can select in Pharo actually.

thanks for the links below. I will try and report results.

Johan

> I'm not sure of these details, but it will give you some things to think 
> about and try (and someone can correct me otherwise).
> * Pharo's default font is still a bitmap StikeFont. * StrikeFont bitmaps are 
> sub-pixel anti-aliased.
> * Sub-pixel anti-aliases
> * Retina display sometimes have sub-pixel rendering turned off, or maybe 
> otherwise problem.
> 
> Try...
> * Choosing a TrueType font
> * Changing some OSX display settings
>   * 
> http://graphicdesign.stackexchange.com/questions/8277/how-does-apples-retina-display-affect-sub-pixel-rendering
>   * 
> http://superuser.com/questions/457153/getting-crisper-fonts-in-os-x-after-switching-from-windows
>   * http://www.macworld.com/article/1145157/smoothsnow.html
>   * 
> http://graphicdesign.stackexchange.com/questions/8277/how-does-apples-retina-display-affect-sub-pixel-rendering


> Please report your results.

Re: [Pharo-users] Pillar 1.1.0 released

[Johan Brichau]

Hi,

I just noticed that in the most recent version of Pillar, the instvar #embedded 
was removed from PRReference
This breaks Pier… though right before this change I could make Pier3 work with 
Pillar just fine.

The embedded var is used to specify that component references are to be 
embedded in the page. There are more components than Figures in Pier.

I am just trying to use and work with Pier3 for Seaside book and website, so it 
would be great if you can consider adding the embedded variable again.

thanks guys!
Johan

ps: email me directly, since I might miss replies via the mailinglist.

> On 07 Sep 2015, at 09:51, Damien Cassou  wrote:
> 
> Cyril Ferlicot and I have polished Pillar 1.0.0 a little. Here is 1.1.0
> changelog:
> 
> - add shebang to generated pillarPostExport.sh
> - improve pillarPostExport.sh messages a little
> - HTML exporter
>  - output a  if and only if the Pillar figure has both a
>caption and a label
> - LaTeX exporter
>  - output a \begin{figure} if and only if the Pillar figure has both
>a caption and a label
> 
> Cyril migrated the list of issues and feature requests from
> smalltalkhub.com to
> 
> https://github.com/pillar-markup/pillar/issues
> 
> Please report issues, describe feature requests and ask questions there.
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
> 

Re: [Pharo-users] Pillar 1.1.0 released

[Johan Brichau]

Hi Cyril,

You are right. It’s better to just fix the version of Pillar for Pier and that 
works just fine for me now.
We will see what happens later if someone has the time to look at Pier.

cheers
Johan

> On 13 Sep 2015, at 12:22, Ferlicot Delbecque Cyril 
>  wrote:
> 
> Le 13/09/2015 10:28, Johan Brichau a écrit :
>> Hi,
>> 
>> I just noticed that in the most recent version of Pillar, the instvar 
>> #embedded was removed from PRReference
>> This breaks Pier… though right before this change I could make Pier3 work 
>> with Pillar just fine.
>> 
>> The embedded var is used to specify that component references are to be 
>> embedded in the page. There are more components than Figures in Pier.
>> 
> 
> Hi Johan,
> 
> We removed that because since Figures are not link anymore we do not
> need it. If the reference is a link, it is not embedded, else it is. We
> plan latter to have more embedded item than Figures, maybe we can just
> and a class between Reference and Figure (PREmbeddedReferences).
> With that we do not need the ivar.
> 
> But since Pier3 doesn't evolve anymore I proposed to someone to freeze
> the version of Pillar needed for the stable version of Pier3. But I
> didn't get an answer.
> 
> --
> Cyril
> 
>> I am just trying to use and work with Pier3 for Seaside book and website, so 
>> it would be great if you can consider adding the embedded variable again.
>> 
>> thanks guys!
>> Johan
>> 
>> ps: email me directly, since I might miss replies via the mailinglist.
>> 
>> 
> 
> 

Re: [Pharo-users] How to set the server debugger in seaside?

[Johan Brichau]

Stef,

You know you can contribute and improve it?

You should remember a bit more the talk of Kim Mackinnon in Cambridge…
This negative way of talking about work of others is not the way to get things 
done. 
I don’t think you would appreciate someone mailing this way about the Pharo 
interface.

In 3.2, the debugger exception handler is the default for development.
There is also the programmatic way of changing this:

(WAAdmin defaultDispatcher handlerAt: ‘YourApp’) exceptionHandler: 
WADebugErrorHandler

cheers
Johan

> On 04 Feb 2016, at 22:42, stepharo  wrote:
> 
> Thanks this is so inintuitive that I forget 5 min after.
> 
> Le 2/2/16 09:56, Cyril Ferlicot Delbecque a écrit :
>> On 02/02/2016 09:47, stepharo wrote:
>>> Hi guys
>>> 
>>> I hate so much this bad configuration interface of seaside.
>>> I lose all the time 20 min to find how to set the debugger.
>>> So I have to do a presentation and I cannot show the debugger.
>>> What a great wonderful experience.
>>> 
>>> How can I configure seaside to get the debugger?
>>> 
>>> Stef
>>> 
>> If I remember well on http://localhost:8080/config add a Filter. Then
>> click on «Configure» next to «WAExceptionFilter». In «Exception Handler»
>> select the debugger.
>> 
> 
> 

Re: [Pharo-users] Is Seaside's Canvas/Brush metaphor for creating HTML available outside of Seaside?

[Johan Brichau]

Depends on what you mean with ‘outside of Seaside’ but maybe this is what you 
would be looking for:

WAHtmlCanvas builder render: [ :html |
html anchor
url: 'htttp://www.seaside.st';
with: 'Seaside Homepage' ]

See WABuilderCanvasTest for some examples.

Hope this helps?
Johan

> On 25 Feb 2016, at 18:21, MartinW  wrote:
> 
> Hi,
> 
> I know, there are templating systems like Mustache, but I always loved
> Seaside's Canvas/Brush metaphor for creating HTML. Is it available as a
> standalone package, so it can be used outside of Seaside?
> 
> Best regards,
> Martin.
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Is-Seaside-s-Canvas-Brush-metaphor-for-creating-HTML-available-outside-of-Seaside-tp4880825.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Is Seaside's Canvas/Brush metaphor for creating HTML available outside of Seaside?

[Johan Brichau]

Well… It’s in a separate package called ‘Seaside-Canvas’.
You should only need Seaside-Core as a prerequisite, as you can derive from the 
metacello config.

I did not try, but let me know if you do.

Johan

> On 25 Feb 2016, at 23:07, stepharo  wrote:
> 
> Hi johan
> 
> What would be good is to have it in a separate package because I wanted to 
> output HTML and loading seaside
> for that was heavy.
> 
> Stef
> 
> 
> Le 25/2/16 19:33, Johan Brichau a écrit :
>> Depends on what you mean with ‘outside of Seaside’ but maybe this is what 
>> you would be looking for:
>> 
>> WAHtmlCanvas builder render: [ :html |
>>  html anchor
>>  url: 'htttp://www.seaside.st';
>>  with: 'Seaside Homepage' ]
>> 
>> See WABuilderCanvasTest for some examples.
>> 
>> Hope this helps?
>> Johan
>> 
>>> On 25 Feb 2016, at 18:21, MartinW  wrote:
>>> 
>>> Hi,
>>> 
>>> I know, there are templating systems like Mustache, but I always loved
>>> Seaside's Canvas/Brush metaphor for creating HTML. Is it available as a
>>> standalone package, so it can be used outside of Seaside?
>>> 
>>> Best regards,
>>> Martin.
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://forum.world.st/Is-Seaside-s-Canvas-Brush-metaphor-for-creating-HTML-available-outside-of-Seaside-tp4880825.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> 
>> 
>> 
> 
> 

[Pharo-users] Seaside 3.1 and 3.2 in Pharo 5

[Johan Brichau]

Hi Pharoers,

If you are looking to use Seaside in Pharo 5, please go ahead and let us know 
if you run into any issues.
Seaside 3.1.5 and 3.2.0 (unreleased) load into Pharo 5 and all tests are green 
[1].

Also: I know the finalization of 3.2.0 is long overdue, so news about that is 
coming soon.

cheers,
Johan

[1] https://ci.inria.fr/pharo-contribution/job/Seaside/ 


“Load release 3.1"
Metacello new
configuration: 'Seaside3';
repository: 
'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
version: #'release3.1';
load.

“Load pre-release 3.2"
Metacello new
configuration: 'Seaside3';
repository: 
'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
version: #’3.2.0';
load

Re: [Pharo-users] Seaside 3.1 and 3.2 in Pharo 5

[Johan Brichau]

Hi Cyril,

> I use Seaside 3.1 in Pharo 5 and I have an application running with this
> setup currently.

Great! There were indeed very few failing tests that were fixed quickly. 
I think most of Seaside was just working and you confirm that.

> This is the main issues I got the past few weeks:
> - When we load Seaside of Pharo 5 we have to add "onWarningLog" in order
> to avoid a lot of deprecation warning.
> - When we register a component to WAAdmin we also have a deprecation
> warning.

For Seaside 3.1.5, this will remain the case. The tests are fixed and the 
broken parts have been replaced but the deprecation warning about #subStrings: 
will not be fixed anymore in Seaside 3.1
For Seaside 3.2, they have been addressed and you should not get any of those 
anymore.

> - In the status component we got a MNU in the VM tab

thanks for reporting, will look into that.

> - In the latest Pharo5 the seaside adaptor is not launched by default on
> 8080. We have to add it manually (probably because of the SessionManager
> changes).

Aha, indeed. The Grease abstraction for this needs to be changed. 
Will take a look asap.

> If I see other problems I will contact you :)

Great. You can also report issues on the issue tracker: 
https://github.com/SeasideSt/Seaside/issues 

> 
> In my baseline I load Seaside3 stable, which is the realise 3.1 I think.

Yes, that’s correct.
I would suggest using 3.2.0 from now on if you’re not running a production 
environment though. It’s still a moving target but it’s good if people 
experiment with it.

cheers
Johan

Re: [Pharo-users] Seaside 3.1 and 3.2 in Pharo 5

[Johan Brichau]

Torsten pointed me to a typo I made for loading version 3.2.0.
This is the correct version:

“Load pre-release 3.2"
Metacello new
configuration: 'Seaside3';
repository: 
'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' 
<http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'>;
version: ’3.2.0';
load

You could also already use the symbolic version #release3.2, but it’s not 
released yet :)
Metacello new
configuration: 'Seaside3';
repository: 
'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' 
<http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'>;
version: #'release3.2';
    load

thx for trying and the feedback!
Johan

> On 20 Mar 2016, at 19:49, Johan Brichau  wrote:
> 
> Hi Pharoers,
> 
> If you are looking to use Seaside in Pharo 5, please go ahead and let us know 
> if you run into any issues.
> Seaside 3.1.5 and 3.2.0 (unreleased) load into Pharo 5 and all tests are 
> green [1].
> 
> Also: I know the finalization of 3.2.0 is long overdue, so news about that is 
> coming soon.
> 
> cheers,
> Johan
> 
> [1] https://ci.inria.fr/pharo-contribution/job/Seaside/ 
> <https://ci.inria.fr/pharo-contribution/job/Seaside/>
> 
> “Load release 3.1"
> Metacello new
> configuration: 'Seaside3';
> repository: 
> 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' 
> <http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'>;
> version: #'release3.1';
> load.
> 
> “Load pre-release 3.2"
> Metacello new
> configuration: 'Seaside3';
> repository: 
> 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' 
> <http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'>;
> version: #’3.2.0';
> load

Re: [Pharo-users] Issue on Seaside beginning

[Johan Brichau]

I think this happens when you load Seaside 3.2 in an image where Seaside 3.0 or 
3.1 is present already.
You need to reinitialize the already loaded applications as follows:

WAEnvironment reloadApplications

and re-register your own applications.

cheers
Johan

> On 04 Jun 2016, at 20:58, Cheikhou Oumar KA  wrote:
> 
> Hi Stef
> 
> > You got a problem with such image
> 
> >   
> > https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
> >  
> > 
> Yes I saved my code in Smalltalkhub. i loaded it in this new image and It 
> works perfectly.
> May be there the problem come from the combination of seaside and teapot in 
> the same packagedon't know. 
> 
> >Sorry for the inconvenience. 
> 
> Don't worry. Thanks a lot. Now I can poursue my exercises.
> 
> Thanks
> 
> 
> 
> 
> 2016-06-04 18:06 GMT+00:00 stepharo  >:
> Hi  Cheikhou
> 
> We will have a look. I will contact Luc and Damien because I do not follow 
> the Seaside set up. 
> May be we messed up with the setup of the seaside image we gave you. 
> Did you save your code?
> 
> So that you can reload it with the 
> https://ci.inria.fr/pharo-contribution/job/Seaside/ 
> 
> Seaside3.2
> 
> 
> You got a problem with such image
> 
> 
> https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
>  
> 
> do you have your code published so that I try to reproduce your problem?
> 
> Sorry for the inconvenience. 
> 
> Stef
> Le 4/6/16 à 19:00, Cheikhou Oumar KA a écrit :
>> Hello.
>> 
>> I am following #PharoMOOC and it become more and more exciting.
>> 
>> I were doing TinyBlog exercise and I got an issue. I looked at the forum but 
>> any solution and I am stuck now like many others.
>> 
>> I have created my class TBApplicationRootComponent, create a server that 
>> listen at :8080 and start it, regiser my application
>> 
>> But at  http://localhost:8080/browse 
>>  I got this Image in my browser
>> 
>> 
>> Any help is welcome.
>> 
>> Thanks
>> 
>> -- 
>> Cheikhou Oumar KA 
>> 奥 马 尔 ·谢 赫 ·嘉
>> Doctorant Informatique
>> cheikho...@gmail.com 
>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> Cheikhou Oumar KA 
> 奥 马 尔 ·谢 赫 ·嘉
> Doctorant Informatique
> cheikho...@gmail.com 
> 
> 
> 

Re: [Pharo-users] [ANN] JSONWebToken

[Johan Brichau]

Hey Norbert,

Also see here: http://smalltalkhub.com/#!/~JohanBrichau/Json-WebToken

;)

Are you using cryptography package?

Cheers,
Johan

> On 22 Jul 2016, at 10:17, Norbert Hartl  wrote:
> 
> Hi,
> 
> thanks to the inquiry of Sven I published an implementation of JSONWebToken 
> to smalltalkhub. It is available at
> 
> http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken
> 
> For those who don't know JSONWebToken or short JWT pronounced "jot" is a 
> token format suitable for authentication and authorization. The token consist 
> of a header, a payload and a signature. The header defines crypto algorithms, 
> compression and other things needed to read a token on reception. The payload 
> is called a claim set which is basically a dictionary with well-known and 
> custom keys. If we think about OAuth or OpenId the values contained map 
> directly to JWT claims. For OpenID connect which is an identification 
> mechanism on top of OAuth the usage of JWT is one of the building blocks. 
> 
> What are the advantages in using JWT?
> 
> - it defines a header for encoding the content so it is quite flexible in the 
> ways compression and encryption of the key is done
> - defines a payload which maps arbitrary keys and there is a set of 
> well-known keys that implementations of OAuth, OpenID can understand
> - defines a signature that makes it easy to trust the information contained 
> or to give the token to someone who is not trusted
> - token format is a single line string so it can be used e.g. in HTTP 
> authentication headers
> 
> A problem JWT can solve:
> 
> In our company we have a lot of little REST servers serving some duties. To 
> minimize the chaos I want to have a central authentication and authorization 
> point. If we assume having 20 images running and we look at typical way how 
> authorization works:
> 
> there is image A (Authentication), image S (Service) und client C. Client C 
> wants to use the service S
> 
> 1. client C authenticates and retrieves authorization information from A (or 
> from S which redirects him to A)
> 2. client C hands out the authorization information to S
> 3. S needs to check at A if the information is valid (client C could have 
> modified it or generated it)
> 4. S grants C access
> 
> Taking the assumption of having 20 service images, every image would need to 
> get back to A in order to check authorization information. The more services 
> images you have the more load it will put on A. In a JWT use case scenario 
> the same would look like
> 
> 1. client C authenticates and receives a JWT containing authorization 
> information. The token is signed by A
> 2. client C hands out JWT to service S
> 3. S checks the signature of A and knows that the authorization information 
> contained is valid. 
> 4. S grants C access
> 
> FYI,
> 
> Norbert
> 

Re: [Pharo-users] Sharing Seaside URLs between users (security) + what is actual way for session expiration page

[Johan Brichau]

> On 21 Sep 2016, at 12:31, Petr Fischer  wrote:
> 
> Hello, two questions about Seaside sessions:
> 
> 1) URL sharing between different users - what if "boss" shares URL from his 
> browser and send it to another regular user - of course, easy way, whole URL 
> with session (_s=) - when another/regular user opens that link -> whole 
> "boss" session opens in regular user's browser, with all "boss" permissions, 
> UI state etc etc - very bad, is there any solution for this? Rewrite every 
> (!) URL with updateURL: is not solution :(

If this is a concern, you can use a cookie for session tracking, but that means 
you cannot have multiple Seaside sessions running in the same browser at the 
same time.

There are probably other ways, but I think the solution is not to rely on a 
session key for authentication.
Here’s a strategy:
Keep the Seaside session key in the url for session tracking but use an 
authorization cookie for authorization. Put that cookie when the user logs in 
and check its presence when requests come in for a session.
I think that using a filter for that is a good choice.

Whenever another user copy/pastes the url, he cannot ‘hijack’ the session 
because he lacks the correct authentication cookie.

> 2) What is the actual way for "session expiration/login page"? There is few 
> tutorials and books on the inet - but info about session expiration is 
> obsolete :( Methods from tutorials not exists in Seaside 3.2.0.
> Some trick with WAApplication subclass is actual?

I’m not sure what the question is. Do you want to redirect users to a page 
whenever the session is expired?

cheers
Johan

Re: [Pharo-users] [Seaside] Seaside can not be used with Pharo 60261

[Johan Brichau]

I only received a config for Grease :)
In my haste, I did not check you need Seaside :)

Right now, I’m a bit too busy so until someone can provide a working config, it 
will have to wait.

cheers
Johan

> On 18 Oct 2016, at 10:19, Norbert Hartl  wrote:
> 
> You uploaded ConfigurationOfGrease but not Seaside. Mistake?
> 
> Norbert
> 
>> Am 18.10.2016 um 10:11 schrieb Johan Brichau :
>> 
>> I uploaded the changes by Christophe. If it does not work, let me know. I 
>> did not try.
>> 
>> cheers
>> Johan
>> 
>> ps: right now the configuration is identical for pharo5.x and pharo6.x. If 
>> things start to fail for Pharo 6, we need to make another baseline to not 
>> break the configuration for pharo 4 and pharo 5
>> 
>>> On 18 Oct 2016, at 10:00, Johan Brichau  wrote:
>>> 
>>> Sure. Christophe Demarey has asked me if he can publish his changes to fix 
>>> the config for pharo 6.
>>> 
>>> I will upload them as soon as I receive them
>>> 
>>> Johan
>>> 
>>>> On 17 Oct 2016, at 21:04, Esteban Lorenzano  wrote:
>>>> 
>>>> this is a question more appropriate for Seaside list :) 
>>>> 
>>>>> On 17 Oct 2016, at 20:07, Pierre CHANSON  wrote:
>>>>> 
>>>>> In #SmalltalkImage>>metacelloPlatformAttributes, #'pharo5.x' 
>>>>> #'pharo5.0.x’ have been removed and Seaside does not have configuration 
>>>>> for pharo6.
>>>>> 
>>>>> Is there a plan to update the configuration of Seaside ?
>>>>> 
>>>>> Thanks !
>>>>> 
>>>>> Pierre and Norbert
>>>> 
>>>> ___
>>>> seaside mailing list
>>>> seas...@lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] [Seaside] Seaside can not be used with Pharo 60261

[Johan Brichau]

Done!

Looked good to me, but I did not test.
If anyone experiences errors, let me know!

Johan

> On 20 Oct 2016, at 11:39, Norbert Hartl  wrote:
> 
> Hi Johan,
> 
> can you please upload the ConfigurationOfSeaside3 I've sent in this thread?
> 
> thanks,
> 
> Norbert
> 
>> Am 18.10.2016 um 17:20 schrieb Johan Brichau > <mailto:jo...@inceptive.be>>:
>> 
>> 
>>> On 18 Oct 2016, at 16:36, Norbert Hartl >> <mailto:norb...@hartl.name>> wrote:
>>> 
>>> (ConfigurationOfAster project version: #development) load
>> 
>> There are issues with this ‘old’ way of Metacello loading. Can you try:
>> 
>> Metacello new
>>  configuration:’Aster’;
>>  version: #development;
>>  load.
>> 
>> (Maybe you need to add the repo to, don’t know).
>> 
>> Cheers
>> Johan
> 

Re: [Pharo-users] Loading Seaside via Bootstrap in Pharo 6

[Johan Brichau]

Hi Sven,

I have (not yet) tried Pharo6, but I saw some people did update the 
configuration for that.
How are you loading the project? Are you using the Metacello load API ?

Johan

> On 20 Feb 2017, at 19:52, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> In my main project I depend on Torsten's Bootstrap project which then loads 
> Seaside. I tried this today on Pharo 6 and it did not work (some internal 
> Seaside dependency could not be resolved). I also noticed that the last 
> commits on Bootstrap were from April 2016. 
> 
> My question now is: is this supposed to work on Pharo 6 ?
> 
> Thx,
> 
> Sven

Re: [Pharo-users] [Seaside] Strange behaviours?

[Johan Brichau]

Hi Alidra,

See here: 
https://stackoverflow.com/questions/42653378/message-order-cascading-on-html-anchor-callback-1-1-with-click-me/42656341#42656341
 


Also, posting your questions on Seaside to the seaside mailinglist is a better 
idea ;)d

cheers
Johan

> On 30 May 2017, at 10:21, Alidra Abdelghani via Pharo-users 
>  wrote:
> 
> 
> From: Alidra Abdelghani 
> Subject: [Seaside] Strange behaviours?
> Date: 30 May 2017 at 10:21:38 GMT+2
> To: pharo-users@lists.pharo.org
> 
> 
> Hi all,
> I just noticed that changing the message send order to an anchor modifies 
> its’ behaviour :
> 
> html anchor with: aString;callback: [doSomething]. -> click on the anchor 
> executes the callback block
> 
> html anchor callback:[doSomething];with:aString. -> click on the anchor does 
> not executes the callback block.
> 
> Is this a normal behaviour?
> 
> I also noticed that instantiating a WAComponent in the same method that calls 
> html render: on it makes the call method in this object fail. See 
> (http://smalltalkhub.com/#!/~Alidra/Seaside_Strange_Call_Behavior 
> ) for an 
> concrete example.
> BTW. I find the name call: quite confusing : you call a method, you pass 
> control to an object. But maybe this is because I am new to Seaside.
> 
> Thank you
> Abdelghani
> 
> 

Re: [Pharo-users] Pharo 7.0.3 Seaside 3

[Johan Brichau]

Before loading, try first disabling the Iceberg Metacello integration in the 
system settings.
I believe this can also be done by evaluating:
Iceberg enableMetacelloIntegration: false.

Also, if you are on windows, do not load the master branch but load the tonel 
branch of Seaside.
So:

Iceberg enableMetacelloIntegration: false.
Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:tonel/repository';
 load


Although the Iceberg integration works just fine for me, I do recall issues 
with crashing images similarly in the past.

Let us know what happens..

Cheers
Johan



> On 26 May 2019, at 11:04, Jeff Gray  wrote:
> 
> Same problem with ZTimestamp.
> However, I tried Complex and that worked ok
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Loading Gettext on already installed Seaside

[Johan Brichau]

I’m afraid the Gettext-Seaside integration is broken in current Seaside 
versions.

Johan

> On 15 Jun 2019, at 00:18, BrunoBB  wrote:
> 
> Well,
> 
> This method exist on GetText GemStone version.
> 
> So i'm not quite sure what is going on. Maybe GS and Pharo version are not
> synchronized.
> 
> regards,
> bruno
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

[Pharo-users] Save the date: October 22nd in Ghent for a Smalltalk WebCamp

[Johan Brichau]

Hi Seaside users,

We are organising a Smalltalk WebCamp day in the Yesplan offices in Ghent on 
October 22nd.

The idea originated in the Seaside channel of the Pharo discord group. However, 
it’s not supposed to be Seaside only. All Smalltalkers doing web development, 
possibly involving other technologies on top of Smalltalk, are encouraged to 
join. Let’s meet and exchange ideas. The topics are to be determined, following 
the idea of an unconference [1], except that, for practical reasons, we will 
ask you to confirm your attendance beforehand.

More info to follow asap. 

Save the date and respond already to the group if you are interested to attend.

Cheers
Johan

[1] https://en.wikipedia.org/wiki/Unconference 

[Pharo-users] Reminder: Smalltalk Webcamp, 22nd of October

[Johan Brichau]

Hi,

Are you doing Web development with Smalltalk? Then this meeting is for you.
We organise an informal meetup on Smalltalk Web Technologies at the Yesplan 
offices.

===
Smalltalk WebCamp
---
Date: Tuesday October 22nd, 2019 (9h30 -> 18h00)
Location: Yesplan offices in Gent, Belgium. (www.yesplan.be 
<http://www.yesplan.be/>)
===

This is an un-conference: everyone is invited to actively participate by 
presenting their project.
Come and share your web development experience with Smalltalk.
Wether you are doing Seaside, Teapot, PharoJS, Amber, SqueakJs, Zinc REST, … or 
anything else that involves Smalltalk and web technologies: come and share your 
experience!

We provide ample time to discuss and collaborate on topics, meet people and 
have a beer in the evening.

Attendance is free, but please register before October 15th if you are 
attending, so we can plan accordingly.
Registration link: 
https://www.eventbrite.com/e/smalltalk-webcamp-tickets-69185265993 
<https://www.eventbrite.com/e/smalltalk-webcamp-tickets-69185265993>

At this time, there are 9 participants, excluding the Yesplan team.

Questions? Please send me an email.

Best regards
Johan Brichau
jo...@yesplan.be <mailto:jo...@yesplan.be>

Re: [Pharo-users] Loading Seaside and Magritte in Pharo8 - baseline load conflicts

[Johan Brichau]

> On 14 Apr 2020, at 11:35, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
>> On 14 Apr 2020, at 11:23, Sebastijan Kaplar  wrote:
>> 
>> MetacelloConflictingProjectError: Load Conflict between existing 
>> BaselineOfGrease [baseline] from github://SeasideSt/Grease:v1.4.x/repository 
>> and BaselineOfGrease [baseline] from 
>> github://SeasideSt/Grease:v1.4.3/repository
> 
> Yes I have seen that also before in other situations, and it is super 
> annoying.
> 
> Apparently, v1.4.x and v1.4.3 are considered different/conflicting.

Yes, because Metacello does not recognise this naming convention. 
Instead, Metacello has/had the question mark as a notation (e.g. v1.4.?) to 
allow this but it also means that it will try to detect the latest version 
which was blowing up the GitHub rate api and thus it became unusable :(

There is a need to fix package versioning and dependencies, but I am not 
following enough to know if there are efforts going on to improve package 
management.

> I don't know if this is a bug or by design.

By design because it considers these versions different since it does not know 
about the naming convention.

> I believe you can solve this with #onConflict directives on the Metacello 
> class, but this also feels like a hack.

Yes, you should solve them yourself.

Johan

[Pharo-users] Grease stream tests failing on Pharo7

[Johan Brichau]

Hi,

I am taking a look at making Grease and Seaside work correctly on Pharo7.

There have been a number of changes to the ReadWriteStream implementation in 
Pharo that break Grease tests: 
https://travis-ci.org/SeasideSt/Grease/jobs/406766720 

It seems ReadWriteStream is broken: the readLimit is almost always wrong 
meaning that the stream `atEnd`, `contents` etc.. return wrong values 

Before I dive into this, I wanted to inquire if anyone is working on this as I 
cannot seem to find any open cases on this on the issue tracker.

cheers
Johan

Re: [Pharo-users] Grease stream tests failing on Pharo7

[Johan Brichau]

Hi,

As I’m diving into the changes and why it fails:

(ReadWriteStream on: ‘abc’) contents
-> = ‘abc’ on Pharo 6
-> = ‘’ on Pharo 7

That seems wrong to me.

(I’ve also sent this question via github on the commit itself 
https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04
 
<https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04>
 )

cheers
Johan

> On 22 Jul 2018, at 10:52, Johan Brichau  wrote:
> 
> Hi,
> 
> I am taking a look at making Grease and Seaside work correctly on Pharo7.
> 
> There have been a number of changes to the ReadWriteStream implementation in 
> Pharo that break Grease tests: 
> https://travis-ci.org/SeasideSt/Grease/jobs/406766720 
> <https://travis-ci.org/SeasideSt/Grease/jobs/406766720>
> It seems ReadWriteStream is broken: the readLimit is almost always wrong 
> meaning that the stream `atEnd`, `contents` etc.. return wrong values 
> 
> Before I dive into this, I wanted to inquire if anyone is working on this as 
> I cannot seem to find any open cases on this on the issue tracker.
> 
> cheers
> Johan
> 
> 

Re: [Pharo-users] Grease stream tests failing on Pharo7

[Johan Brichau]

Hi Richard,

Thanks for pointing out the difference between #on: and #with: instance 
creation methods.

This lead me to discover that ReadWriteStream>>on: strangely sets the readLimit 
instvar to the end… which is not what I would expect.
Removing that method and reversing the change in the commit I mentioned fixes 
all the tests on ReadWriteStream in Grease.

The Grease tests have been written to test the ANSI behavior and, afaik, they 
make sense.

Johan


> On 23 Jul 2018, at 17:51, Richard O'Keefe  wrote:
> 
> (ReadWriteStream on: 'abc') contents
> ==> 'abc' in GNU Smalltalk and Dolphin
> ==> '' in Squeak 6.0 and ST/X
> 
> Here I think we see why ANSI Smalltalk defined #with:
> for {Read,}WriteStreams but not #on:.
> 
> When you recall that ReadWriteStream is a subclass of
> WriteStream in most Smalltalks, and that
> (WriteStream on: (String new: 20))
> or whatever is normally used with the argument of #on:
> expected to provide *workspace*, not *content*, 
> 
> why on earth would you expect
> (ReadWriteStream on: 'abc') contents
> to be different from
> (WriteStream on: 'abc') contents
> which is ''?
> 
> 
> On 23 July 2018 at 21:50, Johan Brichau  <mailto:jo...@inceptive.be>> wrote:
> Hi,
> 
> As I’m diving into the changes and why it fails:
> 
> (ReadWriteStream on: ‘abc’) contents
> -> = ‘abc’ on Pharo 6
> -> = ‘’ on Pharo 7
> 
> That seems wrong to me.
> 
> (I’ve also sent this question via github on the commit itself 
> https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04
>  
> <https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04>
>  )
> 
> cheers
> Johan
> 
>> On 22 Jul 2018, at 10:52, Johan Brichau > <mailto:jo...@inceptive.be>> wrote:
>> 
>> Hi,
>> 
>> I am taking a look at making Grease and Seaside work correctly on Pharo7.
>> 
>> There have been a number of changes to the ReadWriteStream implementation in 
>> Pharo that break Grease tests: 
>> https://travis-ci.org/SeasideSt/Grease/jobs/406766720 
>> <https://travis-ci.org/SeasideSt/Grease/jobs/406766720>
>> It seems ReadWriteStream is broken: the readLimit is almost always wrong 
>> meaning that the stream `atEnd`, `contents` etc.. return wrong values 
>> 
>> Before I dive into this, I wanted to inquire if anyone is working on this as 
>> I cannot seem to find any open cases on this on the issue tracker.
>> 
>> cheers
>> Johan
>> 
>> 
> 
> 

Re: [Pharo-users] Grease stream tests failing on Pharo7

[Johan Brichau]

Hi,

I reported the issue here:
https://pharo.fogbugz.com/f/cases/22281/ReadWriteStream-broken 
<https://pharo.fogbugz.com/f/cases/22281/ReadWriteStream-broken>

Johan

> On 23 Jul 2018, at 20:12, Johan Brichau  wrote:
> 
> Hi Richard,
> 
> Thanks for pointing out the difference between #on: and #with: instance 
> creation methods.
> 
> This lead me to discover that ReadWriteStream>>on: strangely sets the 
> readLimit instvar to the end… which is not what I would expect.
> Removing that method and reversing the change in the commit I mentioned fixes 
> all the tests on ReadWriteStream in Grease.
> 
> The Grease tests have been written to test the ANSI behavior and, afaik, they 
> make sense.
> 
> Johan
> 
> 
>> On 23 Jul 2018, at 17:51, Richard O'Keefe > <mailto:rao...@gmail.com>> wrote:
>> 
>> (ReadWriteStream on: 'abc') contents
>> ==> 'abc' in GNU Smalltalk and Dolphin
>> ==> '' in Squeak 6.0 and ST/X
>> 
>> Here I think we see why ANSI Smalltalk defined #with:
>> for {Read,}WriteStreams but not #on:.
>> 
>> When you recall that ReadWriteStream is a subclass of
>> WriteStream in most Smalltalks, and that
>> (WriteStream on: (String new: 20))
>> or whatever is normally used with the argument of #on:
>> expected to provide *workspace*, not *content*, 
>> 
>> why on earth would you expect
>> (ReadWriteStream on: 'abc') contents
>> to be different from
>> (WriteStream on: 'abc') contents
>> which is ''?
>> 
>> 
>> On 23 July 2018 at 21:50, Johan Brichau > <mailto:jo...@inceptive.be>> wrote:
>> Hi,
>> 
>> As I’m diving into the changes and why it fails:
>> 
>> (ReadWriteStream on: ‘abc’) contents
>> -> = ‘abc’ on Pharo 6
>> -> = ‘’ on Pharo 7
>> 
>> That seems wrong to me.
>> 
>> (I’ve also sent this question via github on the commit itself 
>> https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04
>>  
>> <https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f349de8a4ad03#diff-ba7cc7962a4a22468a18b31fe75ada04>
>>  )
>> 
>> cheers
>> Johan
>> 
>>> On 22 Jul 2018, at 10:52, Johan Brichau >> <mailto:jo...@inceptive.be>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am taking a look at making Grease and Seaside work correctly on Pharo7.
>>> 
>>> There have been a number of changes to the ReadWriteStream implementation 
>>> in Pharo that break Grease tests: 
>>> https://travis-ci.org/SeasideSt/Grease/jobs/406766720 
>>> <https://travis-ci.org/SeasideSt/Grease/jobs/406766720>
>>> It seems ReadWriteStream is broken: the readLimit is almost always wrong 
>>> meaning that the stream `atEnd`, `contents` etc.. return wrong values 
>>> 
>>> Before I dive into this, I wanted to inquire if anyone is working on this 
>>> as I cannot seem to find any open cases on this on the issue tracker.
>>> 
>>> cheers
>>> Johan
>>> 
>>> 
>> 
>> 
> 

[Pharo-users] Pharo7, consistent image freeze/deadlock on snapshotAndQuit

[Johan Brichau]

Hi,

I ran into a freeze issue when trying to save and/or quit an image after 
loading Seaside3 and Zinc (not an infrequent combination :)

The cause seems to be that terminating processes in a `shutDown` handler 
(called on image shutdown / snapshot) leads to a deadlock (somewhere).
Both Comet and Zinc will send #terminate to a process when an image is quit or 
saved. If I disable one of those, the deadlock does not occur.

I managed to reconstruct the issue with a simple example, attached.

The attached Freeze class creates two processes (that loop with a Delay>>wait 
inside) in the `startUp` method (on image start).
These processes are terminated by the shutdown method (called on image 
quit/save).
However, when you try to quit and/or save the image, you will experience an 
image freeze.

I’m not familiar with the process scheduler, or anything else in this context… 
so help would be appreciated while I try to dive further into it :)

To reproduce: just file in the attached file in a Pharo7 image and try to quit.
For reference, System Reporter output for my configuration.

Any ideas?

Cheers
Johan



Freeze.st
Description: Binary data


Image
-
/Users/jbrichau/Pharo/images/Pharo 7.0 - 64bit (development version)/Pharo 7.0 
- 64bit (development version).image
Pharo7.0alpha
Build information: 
Pharo-7.0+alpha.build.1131.sha.a46bfaef44ba209888c92fa0e3bd3a5e04a38c5d (64 Bit)
Unnamed

Virtual Machine
---
/Users/jbrichau/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo
CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c 
Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: 
Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git

Mac OS X built on Jun 28 2018 13:07:33 UTC Compiler: 4.2.1 Compatible Apple 
LLVM 7.3.0 (clang-703.0.31)
VMMaker versionString VM: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 
2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c 
Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018

Re: [Pharo-users] Pharo 7- looking for seaside-REST and RFB

[Johan Brichau]

Sanjay,

Which version of Seaside are you using and from which repository?

Johan

> On 24 Nov 2018, at 07:22, Sanjay Minni  wrote:
> 
> 
> I am migrating my 6.1 application (under develoment) to 7.0 - 
> I have loaded the required packages first thru Catalog Browser (in 7.0) -
> Mandrill, Mustache, Seaside3, VoyageMongo
> 
> How to load the following in 7:
> - seaside-REST - My application looks for WARestfulComponentFilter
> - RFB 
> 
> 
> 
> Sven Van Caekenberghe-2 wrote
>> You need to tell us how are loading Seaside, exactly.
>> 
>> Using 
>> 
>> Metacello new
>> baseline:'Seaside3';
>> repository: 'github://SeasideSt/Seaside:master/repository';
>> load.
>> 
>> ?
>> 
>> The dev build on P7 passes it seems
>> https://travis-ci.org/SeasideSt/Seaside
>> 
>>> On 19 Nov 2018, at 17:34, Sanjay Minni <
> 
>> sm@
> 
>> > wrote:
>>> 
>>> How do I proceed from here ?
>>> 
>>> (Pharo 7 32 bit on Win 10) 
>>> 
>>> whle installing a developed package - Loading stops at
>>> Seaside-Pharo-JSON-Jo5
>>> 
>>> This package depends on the following classes:
>>> WAPharoEncoder
>>> You must resolve these dependencies before you will be able to load these
>>> definitions: 
>>> WAPharoJsonEncoder
>>> WAPharoJsonEncoder>>#delegateOn:
>>> WAPharoJsonEncoder>>#initialize
>>> WAPharoJsonEncoder>>#initializeJsonTable
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> ---
>>> Regards, Sanjay
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> 
> 
> 
> 
> 
> 
> -
> ---
> Regards, Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Pharo 7- looking for seaside-REST and RFB

[Johan Brichau]

Hi Sanjay,

Ok, that’s the latest release.
However, I assume you are upgrading from an earlier version… which version were 
you using before?

Since Seaside 3.2.0 (I believe to recall), we made the default load of Seaside 
much lighter, requiring you to load additional groups explicitly. Before, all 
of Seaside was loaded per default, which posed problems for people who only 
wanted core (for example).

The ‘REST’ group is such an explicit group to load.

So, if you load that group as well. It should work.

I don’t know how the catalog browser works, but I assume you can specify the 
groups to load?
Check out the README on https://github.com/SeasideSt/Seaside 
<https://github.com/SeasideSt/Seaside> to load directly from the git repo and 
use Metacello. There are examples there.

Johan

Ps: Seaside 3.3 should be coming up soon as well, which includes fixes for 
Pharo 7.

> On 24 Nov 2018, at 09:22, Sanjay Minni  wrote:
> 
> Johan,
> 
> Thru monticello browser it shows
> 
> ConfigurationOfSeaside3-JohanBrichau.335 bugfix release 3.2.4
> Repository: smalltalkhub.com/mc/Pharo/MetaRepoForPharo70/main
> 
> if that helps
> 
> 
> 
> Sanjay Minni wrote
>> Johan,
>> 
>> I am installing by going to Pharo 7.0.0rc1->Catalog Browser right click on
>> seaside3 and selecting install stable version. From the messages I presume
>> its installing 3.2.4
>> 
>> if you can tell me how to figure out the Version and Repository I will get
>> the info.
>> 
>> 
>> Johan Brichau-2 wrote
>>> Sanjay,
>>> 
>>> Which version of Seaside are you using and from which repository?
>>> 
>>> Johan
>>> 
>>>> On 24 Nov 2018, at 07:22, Sanjay Minni <
>> 
>>> sm@
>> 
>>> > wrote:
>>>> 
>>>> 
>>>> I am migrating my 6.1 application (under develoment) to 7.0 - 
>>>> I have loaded the required packages first thru Catalog Browser (in 7.0)
>>>> -
>>>> Mandrill, Mustache, Seaside3, VoyageMongo
>>>> 
>>>> How to load the following in 7:
>>>> - seaside-REST - My application looks for WARestfulComponentFilter
>>>> - RFB 
>>>> 
>>>> 
>>>> 
>>>> Sven Van Caekenberghe-2 wrote
>>>>> You need to tell us how are loading Seaside, exactly.
>>>>> 
>>>>> Using 
>>>>> 
>>>>> Metacello new
>>>>> baseline:'Seaside3';
>>>>> repository: 'github://SeasideSt/Seaside:master/repository';
>>>>> load.
>>>>> 
>>>>> ?
>>>>> 
>>>>> The dev build on P7 passes it seems
>>>>> https://travis-ci.org/SeasideSt/Seaside
>>>>> 
>>>>>> On 19 Nov 2018, at 17:34, Sanjay Minni <
>>>> 
>>>>> sm@
>>>> 
>>>>> > wrote:
>>>>>> 
>>>>>> How do I proceed from here ?
>>>>>> 
>>>>>> (Pharo 7 32 bit on Win 10) 
>>>>>> 
>>>>>> whle installing a developed package - Loading stops at
>>>>>> Seaside-Pharo-JSON-Jo5
>>>>>> 
>>>>>> This package depends on the following classes:
>>>>>> WAPharoEncoder
>>>>>> You must resolve these dependencies before you will be able to load
>>>>>> these
>>>>>> definitions: 
>>>>>> WAPharoJsonEncoder
>>>>>> WAPharoJsonEncoder>>#delegateOn:
>>>>>> WAPharoJsonEncoder>>#initialize
>>>>>> WAPharoJsonEncoder>>#initializeJsonTable
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -
>>>>>> ---
>>>>>> Regards, Sanjay
>>>>>> --
>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -
>>>> ---
>>>> Regards, Sanjay
>>>> --
>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> ---
>> Regards, Sanjay
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
> 
> 
> 
> 
> -
> ---
> Regards, Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Pharo 7- looking for seaside-REST

[Johan Brichau]

> On 24 Nov 2018, at 12:30, Sanjay Minni  wrote:
> 
> Also has Seaside REST been ported for Pharo 7 ?  
> as I see there is a line in Catalog Browser 'SeasideREST' but there is an
> error while trying to install

Yeah, 

Somebody put old configurations in that catalog then, because ‘SeasideREST’ 
used to be an add-on project for Seaside 3.0 but it was integrated into main 
Seaside for many years now (I think since 3.1…)

Would be good if somebody removed that: who knows what to do?

cheers
Johan

Re: [Pharo-users] Problem loading seaside with Zinc

[Johan Brichau]

Busy changing this in the BaselineOfSeaside3 as we speak…

Johan

> On 12 Dec 2018, at 20:20, Gabriel Cotelli  wrote:
> 
> You can use the lock API in Metacello to use the dependency you want, 
> ignoring the ones defined in the baselines.
> 
> On Wed, Dec 12, 2018 at 4:16 PM Vitor Medina Cruz  > wrote:
> I can't depend on https://github.com/svenvc/zinc 
>  because this is a transitive dependency, my 
> baseline depends of seaside that depends of Zinc. Is there a way to exclude 
> Zinc dependency from Seaside so that I can force a Zinc dependency definition 
> of my baseline?
> 
> On Wed, Dec 12, 2018 at 5:08 PM Sven Van Caekenberghe  > wrote:
> 
> 
> > On 12 Dec 2018, at 18:56, Vitor Medina Cruz  > > wrote:
> > 
> > Note it is trying to reach http://mc.stfx.eu/ZincHTTPComponents 
> > , which don't seems to be hosting 
> > Zinc anymore. Since these are transitive dependencies, I tried to define 
> > Zinc in the root of my baseline, as I did with seaside (magritte baseline 
> > had some problem with it), but the same error 
> 
> Yes, that machine is partially down, the mc part will come up later, sorry. 
> See my earlier message.
> 
> The best is to depend on https://github.com/svenvc/zinc 
>  using the baseline.
> 
> 

[Pharo-users] Looking for a freelance developer

[Johan Brichau]

Hi Pharoers,

At Inceptive, we are looking for a freelance software developer to help us 
improve our cloud ERP software “Orderflow” (www.orderflow.be 
).
Orderflow is developed in Pharo and deployed in GemStone, using Seaside and 
jQuery/Javascript.

Launched already more than 10 years ago, Orderflow grew steadily and we have 
now reached a point where we need to strengthen the team to sustain further 
growth.

You willl be joining a small team, where communication is direct and to the 
point and where your skills and efforts will be highly visible. So there will 
be no red tape ;-). 
Changes have to be pushed in small chunks and incrementally. I’m sure you’ll 
feel the hart beat of a thriving product.

Orderflow is a highly graphical and customizable document-based workflow system 
that assists clients in managing supplies, purchases, sales, projects, budgets. 
Although it is generally applicable for many kinds of businesses, we are mainly 
active in the educational sector. Large technical schools and catering/hotel 
schools are relying on the software to manage their flow of goods. It is a 
collaborative tool where a lot of people interact with ranging from parents and 
students all the way to the school board. Over the last decade Orderflow has 
grown to become an important player in the Belgian educational market. There 
are over 60 schools that use Orderflow on a daily basis.

Disclaimer: Orderflow is not connected to Yesplan, where you might know me 
from. It is developed using the same wonderful technologies but is a smaller 
and separate project primarily operated by my colleague Thomas. 

Please send any inquiries or reactions to me at jo...@inceptive.be 


Cheers
Johan