- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 905565: 60262

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9055659a7ec02b5755dca212ee0bfae92b9664c8 https://github.com/pharo-project/pharo-core/commit/9055659a7ec02b5755dca212… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-10-18 (Tue, 18 Oct 2016) Changed paths: M Kernel.package/Float.class/instance/comparing/closeTo_.st A Kernel.package/Float.class/instance/comparing/closeTo_precision_.st M Kernel.package/Number.class/instance/comparing/closeTo_.st A Kernel.package/Number.class/instance/comparing/closeTo_precision_.st M Refactoring-Tests-Core.package/RBNamespaceTest.class/instance/class tests/testModelImplementorsSenders.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60261.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60262.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60261.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60262.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60262 19212 Namespace and BrowserEnvironment both now select meta class methods (update test case) https://pharo.fogbugz.com/f/cases/19212 19213 closeTo:precision: should be introduced in Float https://pharo.fogbugz.com/f/cases/19213 http://files.pharo.org/image/60/60262.zip

Oct. 18, 2016

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

by FranÃ§ois Stephany

This is a great overview, thanks for sharing. On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA <masashi.umezawa(a)gmail.com> wrote: > Hi all, > > From Torsten, I've received a request to post about some technical > details of ALLSTOCKER (http://pharo.org/success/AllStocker) . > I hope these notes will be interesting to Pharo web developers. > > - Seaside / Teapot > We are using Seaside as a main framework for ALLSTOCKER marketplace. > Seaside's component architecture is great for extending application in > an organized way. > ALLSTOCKER prototype was originally composed of only 3 class > categories. Now these were gradually grown to 70 categories. But we > still feel that they are manageable. > We also use Teapot for building Web-based API in a quick way. Recently > we've built webhook handlers for integration with other services. > > - Templating with Mustaside > We need a lot of responsive-design web pages for supporting various > mobile devices. (It is important especially for Southeast Asian > countries, where tablets are popular than PCs). > We would like to adopt existing Twitter Bootstrap templates for saving > time. So, Mustaside was our choice. > http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside > Before Mustaside, there were a lot of noisy #div: sends in our code. > Now they are gone. > > - Localization > Our business target is world-wide. So localization is very important > topic. Currently ALLSTOCKER supports 4 languages and we will add > Chinese languages soon. > Translation strings are not only in Smalltalk code, but also in > Mustache templates. So we selected Soup for extracting translatable > strings in those templates. > http://smalltalkhub.com/#!/~PharoExtras/Soup > For managing translations, we use Gettext package. > http://smalltalkhub.com/#!/~PharoExtras/Gettext > > - Databases > For transactional data, we chose Glorp. Although there are mapping > costs, we prefer RDB (Postgres). It is reliable for handling precious > order-related data. > However, for supporting complex search of machines, we use Neo4j - a > graph database. It supports very powerful query language called > Cypher. > We can avoid complex table joins and get aggregated results faster. > http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt > > - Keyword search > ALLSTOCKER supports free keyword search. We selected Elasticsearch for > search-engine. Elasticsearch has elaborated searching facilities and > those are easily accessible via REST API. > We have extended the existing Elasticsearch client for Pharo 5. > https://github.com/newapplesho/elasticsearch-smalltalk > > - Deployment > We are using AWS Elastic Load Balancer and running Nginx as a > front-end web server. Two back-end Pharo images are running and > load-balanced with sticky sessions. > It was sort of difficult to find the appropriate simultaneous number > of database connections and Pharo processes. We feel ALLSTOCKER is > pretty stable for now, but we need to adjust more for expanding our > services. > > Best regards, > -- > [:masashi | ^umezawa] > >

Oct. 18, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sven Van Caekenberghe

> On 18 Oct 2016, at 03:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> You could try doing... allowComplexMapKeys: true >> ... > > Hmm, if the default writing may use complex keys, shouldn't the default > reading do the same? I found it jarring to write using the defaults, and > then have the default read fail! Yes, you are right, the default should be true, I can't remember why I did not yet do it, it feels as if I am forgetting something, don't see all the consequences. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919141.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 18, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > allowComplexMapKeys: true BTW that worked. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919142.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 18, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > You could try doing... allowComplexMapKeys: true > ... Hmm, if the default writing may use complex keys, shouldn't the default reading do the same? I found it jarring to write using the defaults, and then have the default read fail! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919141.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 18, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sven Van Caekenberghe

> On 17 Oct 2016, at 21:14, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> I copy pasted them from the latest STON package. Thanks. > > Ugh. > > FileLocator home / 'Downloads' / 'myfile.ston' writeStreamDo: [ :s | > STON put: myDB onStream: s]. > > and then > > FileLocator home / 'Downloads' / 'myfile.ston' readStreamDo: [ :s | > STON fromStream: s ] > > resulted in: "STONReaderError: At character 978274: unexpected property name > type" > > Any thoughts on how to debug? That obviously depends on what 'myDB' contains, the basic call is OK though: FileLocator home / 'Downloads' / 'myfile.ston' writeStreamDo: [ :s | STON put: STONTestUser dummy onStream: s ]. FileLocator home / 'Downloads' / 'myfile.ston' readStreamDo: [ :s | STON fromStream: s ]. The error you get basically means that something non-simple was used as property name. You could try doing: FileLocator home / 'Downloads' / 'myfile.ston' readStreamDo: [ :s | (STON reader on: s) allowComplexMapKeys: true; next ]. >From the class comment of STONReader - allowComplexMapKeys <Boolean> default is false if true, any object is allowed as map key if false, only strings, symbols and numbers are allowed as map keys > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919109.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 17, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Sean P. DeNigris wrote > I copy pasted them from the latest STON package. Thanks. Ugh. FileLocator home / 'Downloads' / 'myfile.ston' writeStreamDo: [ :s | STON put: myDB onStream: s]. and then FileLocator home / 'Downloads' / 'myfile.ston' readStreamDo: [ :s | STON fromStream: s ] resulted in: "STONReaderError: At character 978274: unexpected property name type" Any thoughts on how to debug? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919109.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Hmm, Path (the superclass) is handled, it has custom #stonOn: and > #fromSton: implementations. Do you have them in your image ? They are not included in the stable version from either the Pharo 4.0 MetaC Browser, or Pharo 5.0 Catalog browser, but I copy pasted them from the latest STON package. Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919099.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2016

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

by Serge Stinckwich

Dear Masahi-san, thank you for your detailed explanations ! This is always great to see that nice tools like that exist in Pharo ecosystem and that people can do business with them. Regards, On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA <masashi.umezawa(a)gmail.com> wrote: > Hi all, > > From Torsten, I've received a request to post about some technical > details of ALLSTOCKER (http://pharo.org/success/AllStocker) . > I hope these notes will be interesting to Pharo web developers. > > - Seaside / Teapot > We are using Seaside as a main framework for ALLSTOCKER marketplace. > Seaside's component architecture is great for extending application in > an organized way. > ALLSTOCKER prototype was originally composed of only 3 class > categories. Now these were gradually grown to 70 categories. But we > still feel that they are manageable. > We also use Teapot for building Web-based API in a quick way. Recently > we've built webhook handlers for integration with other services. > > - Templating with Mustaside > We need a lot of responsive-design web pages for supporting various > mobile devices. (It is important especially for Southeast Asian > countries, where tablets are popular than PCs). > We would like to adopt existing Twitter Bootstrap templates for saving > time. So, Mustaside was our choice. > http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside > Before Mustaside, there were a lot of noisy #div: sends in our code. > Now they are gone. > > - Localization > Our business target is world-wide. So localization is very important > topic. Currently ALLSTOCKER supports 4 languages and we will add > Chinese languages soon. > Translation strings are not only in Smalltalk code, but also in > Mustache templates. So we selected Soup for extracting translatable > strings in those templates. > http://smalltalkhub.com/#!/~PharoExtras/Soup > For managing translations, we use Gettext package. > http://smalltalkhub.com/#!/~PharoExtras/Gettext > > - Databases > For transactional data, we chose Glorp. Although there are mapping > costs, we prefer RDB (Postgres). It is reliable for handling precious > order-related data. > However, for supporting complex search of machines, we use Neo4j - a > graph database. It supports very powerful query language called > Cypher. > We can avoid complex table joins and get aggregated results faster. > http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt > > - Keyword search > ALLSTOCKER supports free keyword search. We selected Elasticsearch for > search-engine. Elasticsearch has elaborated searching facilities and > those are easily accessible via REST API. > We have extended the existing Elasticsearch client for Pharo 5. > https://github.com/newapplesho/elasticsearch-smalltalk > > - Deployment > We are using AWS Elastic Load Balancer and running Nginx as a > front-end web server. Two back-end Pharo images are running and > load-balanced with sticky sessions. > It was sort of difficult to find the appropriate simultaneous number > of database connections and Pharo processes. We feel ALLSTOCKER is > pretty stable for now, but we need to adjust more for expanding our > services. > > Best regards, > -- > [:masashi | ^umezawa] > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 17, 2016

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

by Esteban A. Maringolo

Thank you for sharing all your experience. I wasn't aware of many of the packages you're using. And I like the Mustaside approach for certain parts of a Seaside app. It still surprises me how these packages can fly so low under the radar. What version of Glorp are you using? Best regards! Esteban A. Maringolo

Oct. 17, 2016