September 2014 - Pharo-users

Re: [Pharo-users] [ANN] JSON datatype support in PostgresV2 package

by Esteban A. Maringolo

As a side note to this discussion: Postgres Outperforms MongoDB and Ushers in New Developer Reality http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-u… Maybe there could be a VoyagePostgresql alternative for anyone insterested ;-) Regards! Esteban A. Maringolo 2014-09-05 10:23 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-09-05 4:18 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 04 Sep 2014, at 21:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> Even though I don't use PharoExtras/JSON for my daily JSON >>> manipulation (I use Seaside-JSON and NeoJSON), I found it to be the >>> most "modular"/"independent" JSON package out there. >> >> I don't see how the JSON and NeoJSON package differ in that respect. NeoJSON has no dependencies. Could you explain this point ? > > My Bad, I didn't mean exactly that. > When I wrote the above paragraph I thought NeoJSON required the > specification of a schema and couldn't simply convert JSON strings to > Dictionaries. > > The only thing I like about PharoExtras/JSON is the fact JsonObject > allows its direct manipulation without having to use dictionary > accessors, but still allowing for it (because JsonObject IS a > Dictionary). > > We can perfectly replace it by NeoJSON. Mine was a proof of concept, > which once I debugged through a lot types of PGPacket ended up being > simpler than thought. Supporting parametrized statements with JSON is > something I would like to check (I guess it is only text). Adding > support to jsonb type is linear too on the client side, just replicate > what I did for json. > > > > I did a quick benchmark comparing JSON parsers and NeoJSON gets > slightly faster as the stream gets larger. I didn't profile them > memorywise. > > 31bytes JSON: > NeoJSON: 73,600 per second. > JSON: 42,700 per second. > WAJsonParser: 79,400 per second. > > 309bytes JSON: > NeoJSON: 14,200 per second. > JSON: 12,400 per second. > WAJsonParser: 13,900 per second. > > 17215bytes JSON: > NeoJSON: 277 per second. > JSON: 194 per second. > WAJsonParser: 255 per second. > > https://gist.github.com/eMaringolo/5e7c865188036faa7202#file-json-bench

Sept. 30, 2014

Re: [Pharo-users] Unicode support in Pharo

by Alain Rastoul

Le 29/09/2014 19:15, Sven Van Caekenberghe a Ã©crit : > > On 29 Sep 2014, at 19:10, Robert Shiplett <grshiplett(a)gmail.com> wrote: > >> Must be a thing about European "guys" ... >> >> <quote> >> >> - ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code >> (again will be transparent to most users for same reason). >> >> </unquote> >> >> Of all reasons to retain ByteString, let's hope this one is not listed, lest we appear ridiculous in our threads. > > Apart from being incorrect, it is indeed a totally wrong formulation which furthermore gives a bad impression. > > ByteString is simply an optimisation covering Strings where all characters use the lower 256 Unicode code points. > Indeed, there is something about "europe" : the iso alphabet soup http://czyborra.com/charsets/iso8859.html which is/was a pain for years now (thank you unicode). But you are right, this formulation is not good, yours is far better. :)

Sept. 30, 2014

Alien datasize

by Annick Fron

Hi, I am very surprised to see that : Alien newC: has 8 bytes (data size = 8) , which is consistent with a 64 bit architecture but not with a 32 one ! What is the problem ? Annick

Sept. 30, 2014

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Damien Cassou

On Mon, Sep 29, 2014 at 9:03 PM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > How to proceed? 1- please give me your github username 2- clone https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english 3- read the README and add your chapter If you prefer, you can also send a pull request. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 30, 2014

Re: [Pharo-users] Pharo 32 bits

by Annick Fron

Thank you. I have just discovered that my C library uses 64 bit integers on a 32 bits platform â¦But Alien is resilient to that ! Annick Le 29 sept. 2014 Ã 13:05, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > This is on a 32-bit Ubuntu 13.10 > > $ uname -a > Linux stfx 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:36:13 UTC 2013 i686 i686 i686 GNU/Linux > > $ curl get.pharo.org/30+vm | bash > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 2885 100 2885 0 0 19171 0 --:--:-- --:--:-- --:--:-- 19233 > Downloading the latest 30 Image: > http://files.pharo.org/image/30/latest.zip > Pharo.image > Downloading the latest pharoVM: > http://files.pharo.org/vm/pharo/linux/stable.zip > pharo-vm/pharo > Downloading PharoV10.sources: > http://files.pharo.org/sources//PharoV10.sources.zip > Downloading PharoV20.sources: > http://files.pharo.org/sources//PharoV20.sources.zip > Downloading PharoV30.sources: > http://files.pharo.org/sources//PharoV30.sources.zip > Creating starter scripts pharo and pharo-ui > > $ file pharo-vm/pharo > pharo-vm/pharo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd88118f34ce96590cabfada3172b5f153b92e88e, not stripped > > On 29 Sep 2014, at 13:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> AFAIK the Pharo VM *is* 32-bit. >> >> On 29 Sep 2014, at 12:57, Annick Fron <list(a)afceurope.com> wrote: >> >>> Is it possible to download a 32 bits linux pharo vm ? >>> >>> Annick >>> >> > >

Sept. 30, 2014

Re: [Pharo-users] Versioneer. nice. mmMmmm...

by kilon alios

Actually the best thing to do when you 2 choices is to pick the third one. In this case its what I call "double mode" , you see it quite frequently with software synthesizer, as you can imagine a synthesizer is a complex electronic music instrument that can reach up to thousand of parameters easily so what designers have done is to create an easy mode and an advanced mode. In easy mode is for those that want to create sounds on the go, usually that means around 10-30 parameters buttons and advanced mode is divided into panels that can expanded collapse to control the complexity of the GUI that may contain even thousands of parameters. GUI design is a science and an art but yes you can have your cake and eat it too. I think with Versioner we can keep it small for now and then if it get a bit more complex go for a double mode. About collaboration if you are familiar with git and github then nothing can beat this workflow . You create a repo in gihub, I fork it, and I then send pull requests to you, pull requests do not affect your code and you can choose what to merge and not to merge giving you complete control and me the safety that I wont brake anything. You can also comment the code directly using github web interface and of course the issue tracker for any issue that may be reported. If you are not familiar with git or dont want to us it , I have no issues committing to smalltalkhub , I will create a mirror repo in github anyway for my work since this is how I work when it comes to my Pharo projects. The choice is your, I will now start studying the code and see what I can bring to it. On Tue, Sep 30, 2014 at 4:15 PM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > > Le 30 sept. 2014 Ã 11:15, kilon alios a Ã©crit : > > > Not really, not if you are a begineer like me and does not come to mind > to right click on the entry. A GUI should have as button all the basic > functionality. Obviously not all functionality should be crammed into a GUI > , though depending on the design thats possible too. > > I understand your point. At the same time, I took care to not put too many > buttons on the UI to avoid users to be lost. The best thing to do should be > in the middle. > > > > > Also I do feel Versioneer can be an excellent tool even replacing > Configuration Browser, allowing users to browse through projects in > metarepo repositories and choose specific version for each package to load, > even display information for those packages. > > I also have this feeling. We should just take care to give a way to load a > configuration that is not in any metarepo repository. > > > I love the tool as it is, but I do feel there is a lot more potential in > it and I am willing to contribute if that is desirable. > > Of course, all contributors are welcomed. I'm already working from time to > time with Diego to merge his Metaceller model with Versionner model. It > will open doors to support platform-specific code in dependencies. > I just added you to Versionner contributors. If you want to contribute, > please ask me which version to start with because Monticello is a hell to > manage parrallel development? > > Cheers, > Christophe. > >

Sept. 30, 2014

Re: [Pharo-users] Versioneer. nice. mmMmmm...

by Christophe Demarey

Le 30 sept. 2014 Ã 11:15, kilon alios a Ã©crit : > Not really, not if you are a begineer like me and does not come to mind to right click on the entry. A GUI should have as button all the basic functionality. Obviously not all functionality should be crammed into a GUI , though depending on the design thats possible too. I understand your point. At the same time, I took care to not put too many buttons on the UI to avoid users to be lost. The best thing to do should be in the middle. > > Also I do feel Versioneer can be an excellent tool even replacing Configuration Browser, allowing users to browse through projects in metarepo repositories and choose specific version for each package to load, even display information for those packages. I also have this feeling. We should just take care to give a way to load a configuration that is not in any metarepo repository. > I love the tool as it is, but I do feel there is a lot more potential in it and I am willing to contribute if that is desirable. Of course, all contributors are welcomed. I'm already working from time to time with Diego to merge his Metaceller model with Versionner model. It will open doors to support platform-specific code in dependencies. I just added you to Versionner contributors. If you want to contribute, please ask me which version to start with because Monticello is a hell to manage parrallel development? Cheers, Christophe.

Sept. 30, 2014

Re: [Pharo-users] UI testing

by Tudor Girba

Hi, Glamour comes with an extensive Morphic test suite. You can check it here in the subclasses of GLMMorphicTest. The superclass also has a number of utility methods. The checking is done via excellent additions to Morphic (I believe by Sean). See for example this: GLMTextMorphicTest>>testAcceptKeyCanBeOverriden | composite textMorph overriden | overriden := false. composite := GLMCompositePresentation new with: [ :a | a text act: [ :text | overriden := true ] on: $s entitled: 'Override']. window := composite openOn: 4. textMorph := self find: PluggableTextMorph in: window. textMorph simulateClick. self simulateKeyStroke: $s command. self simulateKeyStroke: $s control. self simulateKeyStroke: $s alt. self assert: overriden. Cheers, Doru On Tue, Sep 30, 2014 at 11:00 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hi all, > > Is there anything in Pharo that supports UI testing? > What I would like to achieve is to be able to simulate a click, select a > menu item, input some text in text fields, Ok/Cancel button click, and some > other basic task for the automation of my tests. > > With Glamour, I can simulate transmissions programatically and then test > for the display values in the presentations or dig the resulting morph > structure to test for specific information. The problem with dialog boxes > is that once launched, I cannot perform anything in the system because my > test code is active only when dialog boxes get their intended input and are > validated. > > So, if there is anything for simulating testing "scenarios" (click on > second button -> select third menu item -> fill up text field -> select > color -> ok button -> test fourth PanelMorph in the window ), it would be > really helpful and make my testing much more productive. > > regards, > > usman > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2014

Re: [Pharo-users] UI testing

by Sven Van Caekenberghe

Spec UI are reasonably testable as well, this tutorial contains a sub section doing just that: https://medium.com/@svenvc/rediscovering-the-ux-of-the-legendary-hp-35-scie… But testing dialogs is indeed a challenge ;-) On 30 Sep 2014, at 11:32, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Tx Marcus. > I'll have a look at what this infrastructure already offers to see if I can use it directly or with some enhancements. > > usman > > On Tue, Sep 30, 2014 at 11:22 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 30 Sep 2014, at 11:00, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > Hi all, > > > > Is there anything in Pharo that supports UI testing? > > What I would like to achieve is to be able to simulate a click, select a menu item, input some text in text fields, Ok/Cancel button click, and some other basic task for the automation of my tests. > > > > With Glamour, I can simulate transmissions programatically and then test for the display values in the presentations or dig the resulting morph structure to test for specific information. The problem with dialog boxes is that once launched, I cannot perform anything in the system because my test code is active only when dialog boxes get their intended input and are validated. > > > > So, if there is anything for simulating testing "scenarios" (click on second button -> select third menu item -> fill up text field -> select color -> ok button -> test fourth PanelMorph in the window ), it would be really helpful and make my testing much more productive. > > > > There is UITestCase (see the subclasses), e.g. > > testSimulateClick > "self run: #testSimulateClick" > > morph := TextMorph new contents: ''; openInWorld. > morph simulateClick. > self assert: morph hasKeyboardFocus. > > > But it definitely needs more e.g. for pressing buttons and things like that. > > Marcus >

Sept. 30, 2014

Re: [Pharo-users] UI testing

by Usman Bhatti

Tx Marcus. I'll have a look at what this infrastructure already offers to see if I can use it directly or with some enhancements. usman On Tue, Sep 30, 2014 at 11:22 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 30 Sep 2014, at 11:00, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > Hi all, > > > > Is there anything in Pharo that supports UI testing? > > What I would like to achieve is to be able to simulate a click, select a > menu item, input some text in text fields, Ok/Cancel button click, and some > other basic task for the automation of my tests. > > > > With Glamour, I can simulate transmissions programatically and then test > for the display values in the presentations or dig the resulting morph > structure to test for specific information. The problem with dialog boxes > is that once launched, I cannot perform anything in the system because my > test code is active only when dialog boxes get their intended input and are > validated. > > > > So, if there is anything for simulating testing "scenarios" (click on > second button -> select third menu item -> fill up text field -> select > color -> ok button -> test fourth PanelMorph in the window ), it would be > really helpful and make my testing much more productive. > > > > There is UITestCase (see the subclasses), e.g. > > testSimulateClick > "self run: #testSimulateClick" > > morph := TextMorph new contents: ''; openInWorld. > morph simulateClick. > self assert: morph hasKeyboardFocus. > > > But it definitely needs more e.g. for pressing buttons and things like > that. > > Marcus >

Sept. 30, 2014