August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PharoJS fails at first attempt

by Frank-B

@Serge and @those who developed PharoJS My first attempt to play with PharoJS failed. See here: http://forum.world.st/PharoJS-crashes-at-first-try-tp4960686.html Actually, this is what I had expected, because it resembles (unfortunately) my general experience with Squeak/Pharo from several occaisional attempts to use them. -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 13, 2017

PharoJS crashes at first try

by Frank-B

As recommended here: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-td4960519.… by @Serge, I loaded the code and tried to run it. But, I almost tend to say "as usual", *it fails at first try*! I "did" the code in the Playground window but nothing happens, no code is written into the selected directories. When I do "inspect it", I get a window (see screenshots), which does not really tell me either, what has happened (due to my lack of Pharo knowledge). Despite my over 20 years of full-time Smalltalk development, I have NOT any experience with either Squeak nor Pharo and most of my attempts to use them were very frustrating. Also, I do not feel like trying around, if and because: - even the very first test fails immediately - there is no meaningful documentation available - the classes I looked at were all undocumented (for me, a 100% no-go, never ever acceptable) And then, of course, also the test cases fail, because there is nothing in the diretories, where some earlier output was expected. Pardon, but professionality and confidence causing systems look very different too me. I am writing this with sadness, because it is certainly not my first such experience in the Squeak/Pharo area. There are some very bright people engaged here, but for some reason many of them lack some important aspects to be called professionals. Just FYI: My very first application software, an "ERP" system, which I started developing more than 35 years ago in horrible Basic, is still feeding a company (not mine) with >25 people as their sole product and has a couple of hundred business users. Some of my former staff is still working there and they said, this is only possible because I did force them "dictatorially" to document / comment every single line of code. In the beginning, they hated me for that. Today they are very thanksful. P.S. I DO have a very fast horse, because this is what one needs when telling the truth - in these days when truth is the worst "hate crime". -- View this message in context: http://forum.world.st/PharoJS-crashes-at-first-try-tp4960686.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 13, 2017

PharoDays17: Bloc video - displaying metrics while prototyping

by Ben Coman

I was watching PharoDays17: Bloc video and @53:15 there was a question due to offset being negative... https://youtu.be/ikzkzfz0zAA?t=3197 ...and I had a random idea (so not necessarily practical) that since we have "metrics" as an object, I wonder if a built in feature to draw these metrics on the canvas - kind of a developer guidelines to be used temporarily during prototyping. Something like... metrics red drawOn: aCanvas which would be commented out of production code. Now what I'm really interested in is a zoomable image window, preferably using the mouse wheel. Any chance such example if available somewhere? cheers -ben

Aug. 13, 2017

Re: [Pharo-dev] Orca versus PharoJS

by Frank-B

@Serge Merci beaucoup for the recommendation but I had looked at the PharoJS page a few times before and I had not touched it, simply because it's the usual thing that there is absolutely no meaningful information, description, features list etc available. The slides don't really tell anything either and the FAQ mainly tells where to get cups and shirts (ok that was nasty). There are so many merely academic pseudo-solutions especially in the Squeak and Pharo area, most of which have never really made it to production state, that over the years I have become extremely sceptical. It's a great pity in my eyes, because there are definitely many very bright people engaged there and here. Unfortunately, many if not most Smalltalkers are very far away in their perception and thinking from the end-users. The Orca docs are just the total opposite, they are very detailed, extremely professional and very convincing. But I don't know yet about the code behind and because of that I will now give PharoJS a try and look at it. -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 13, 2017

Orca versus PharoJS

by Frank Berger Software

@Serge Merci beaucoup for the recommendation but I had looked at the PharoJS page a few times before and I had not touched it, simply because it's the usual thing that there is absolutely no meaningful information, description, features list etc available. The slides don't really tell anything either and the FAQ mainly tells where to get cups and shirts (ok that was nasty). There are so many merely academic pseudo-solutions especially in the Squeak and Pharo area, most of which have never really made it to production state, that over the years I have become extremely sceptical. It's a great pity in my eyes, because there are definitely many very bright people engaged there and here. Unfortunately, many if not most Smalltalkers are very far away in their perception and thinking from the end-users. The Orca docs are just the total opposite, they are very detailed, extremely professional and very convincing. But I don't know yet about the code behind and because of that I will now give PharoJS a try and look at it.

Aug. 13, 2017

Github and Fogbugz integration

by Guillermo Polito

Hi all, we just configured fogbugz and github integration as follows: http://help.fogcreek.com/8048/integration-with-git Quoting the instructions: 1. Now you can refer to your FogBugz cases in your GitHub commits (just add â*case <number>*â in the commit message) That will link your fogbugz issues to the commits on integration. Sadly, this just works for the integration of commits into the main branches, not pull requests. For pull request integration we will probably need a home made solution. Cheers, Guille et al -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 13, 2017

Re: [Pharo-dev] Using Orca for a modern 'sexy' Smalltalk User Interface

by serge.stinckwich＠gmail.com

You should have a look to PharoJS that allows you to deploy Pharo app in the browser: https://pharojs.github.io/ PharoJS is fully supported. EnvoyÃ© de mon iPhone > Le 13 aoÃ»t 2017 Ã 13:42, Frank-B <frank.berger.software(a)web.de> a Ã©crit : > > @Stephan > > Granted and agreed! > > But that does not explain why it seems that nobody has really used this > obviously brilliant Orca approach! > > In my view, this Orca approach seems by far 'better' in many respects than > some pseudo-solutions that expect us to program in the browser (= just > absurd) and which neglect the gigantic advantages of our Smalltalk IDEs over > the JavaScript world. > > Any Smalltalker who has ever tried to develop a bigger piece of JavsScript > code (like I did) must have been disgusted by the stone-age status of the > available tools and should welcome the availability to develop client-server > solution entirely in Smalltalk. > > And today, with the availability of WebSockets, there should even be far > better ways of having an Orca-based client communicate with a Smalltalk > driven server on a message-passing level. It seems that WebSockets have not > been used in Orca in 2011 and before, but it should not be problem to add > them. > > Further, I see TIRADE by GÃ¶ran Krampe > http://goran.krampe.se/category/tirade/ as another useful addition. > > But most importantly, Orca should be the basis for a much better alternative > to this (in my view) insane, ugly and very slow Seaside. > > Orca is the perfect tool to create a modern and entirely browser-based user > interface with ONE single source code for browser AND desktop based > Smalltalk driven applications. > > This would overcome our (Smalltalk in general) greatest deficiency and that > has always been the user-interface, which is the by far most decisive > success factor for every application software today. > > Look at the *Smalltalk UI status*, which for me is still nothing but a > *tragedy*: > > Desk-top only UI definitions exist in *VA and Dolphin* where Dolphin is at > least close to what most users consider and expect as the standard and that > is, if we like it or not, Windows. > > The same is true for VW where the *VisualWorks UI* is internally totally > insane, undocumented, old-fashioned in many aspects, not multi-lingual at > all (despite their claims), 'polling', itâs simply âkaputtâ from the very > beginning. > > *Squeakâs UI* is out of any discussion and *Pharoâs UI* is somewhat more > modern but miles away from what end-users expect and tolerate, not to > mention what they would love as an application UI. > > Having separate UI code for the desk-top and the browser is a sick idea > anyway and therefore NO Smalltalk today is really suitable for developing > modern, end-user friendly, simply âsexyâ user interfaces. > > I have always been convinced that the total absence of a 'good UI' in > Smalltalk for desk-top and browser has been *the major reason for > Smalltalk's failure* to attract a large and prefessional (developers of > wide-spread standard software) user-base, apart from the greed [Goldberg] > and arrogance towards the UI and the absurd licensing conditions and > price-wishes of the early managers not only at ParcPlace but also at their > successors (some of their licencing is rather slavery). > > Shouldn't we finally change this sad situation? > > > > -- > View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 13, 2017

eventual crashes pharo vm

by henry

Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers http://www.squeaksource.com/TurquoiseTesting.html - HH

Aug. 13, 2017

Re: [Pharo-dev] New line on command line

by Guillermo Polito

Rajula, you can debug the code in graphical mode also. Would you mind investigating the bug and proposing a fix? It should not be difficult :) Guille On Sat, Aug 12, 2017 at 3:39 PM, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > > Hi Rajula > > Hey > > > > On Sat, Aug 12, 2017 at 12:56 AM, Rajula Vineet <[hidden email]> wrote: > > Hey, > > I have been trying to print on the command line as a part of my > handler > implementation. I have been using `nextPutAll: aString;lf.` > Apparently, 'lf' > does not seem to work. I tried 'cr' too. I am using the latest 7.0 > Pharo-vm > and pharo image. I tried 'OSPlatform current lineEnding' as > suggested by > Clement Mastin. But, when I used the 6.0 version the 'lf' message > is working > fine. > > > We did some changes to remodularize a bit more the kernel some weeks > ago. > > The correct way to print a line ending is, as Clement pointed out, > 'OSPlatform current lineEnding'. That is because there is no portable > character for a new line. Each platform has its own. > > Oh! Cool! > > That said, maybe you found a bug :). Since the image before > automatically transformed cr's in line endings for a platform, I did a > stream decorator that replaces that behaviour for Pharo 7, I just did it to > make it work, did not test it further actually. > > Oh! Yeah, it might be a bug. > > Could you try the following? > > - seeing what happens if you print a new line twice? > nextPutAll: aString; lf;lf > > I tried it out, it is not changing anything. No new line. > > - What is the stream you're using to print out? Transcript or > Stdout? Could you show the entire expression you're using? > > Yeah, I am using stdout. This is the expression > self stdoutnextPutAll: (SystemVersion current highestUpdate) asString;lf. > > - Can you print out the stream you're using? > stream nextPutAll: stream asString; lf. > > Yeah, the stream I am using is a VTermOutputDriver. > > Guille > > Rajula > > Please find the attached image which demonstrates the same. The > left > terminal is of version 7.0, right one is of 6.0. Can someone help > me out > with this? > <http://forum.world.st/file/n4960327/Screenshot_from_2017- > 08-11_00-04-29.png> > > > > -- > View this message in context: http://forum.world.st/New- > line-on-command-line-tp4960327.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- > > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - http://www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > ------------------------------ > View this message in context: Re: New line on command line > <http://forum.world.st/New-line-on-command-line-tp4960327p4960423.html> > > Sent from the Pharo Smalltalk Developers mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at > Nabble.com. > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 13, 2017

Re: [Pharo-dev] Is there a portable way to check if a string is a block?

by Guillermo Polito

RBParser parseMethod: '...' parses a method RBParser parseExpression: '...' does it for an expression But I think both of them return a method node? I cannot recall. However, you can always do at the end node methodNode statements last isBlockNode or something like that. Can't you? On Sun, Aug 13, 2017 at 4:32 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Mariano, > > _,,,^..^,,,_ (phone) > > On Jul 24, 2017, at 9:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi guys, > > Is there a portable (that would work in GemStone too) and safe way to know > if a String would be a block? > > I must support this kind of strings: > > 'singleString' -> false > 'multi string' -> false > ' [:a | 42]' -> true > ' '' '' [:a | 42]' -> true > '[:a | 42]' -> true > ' "a commet" [:a | 42]' -> true > ' WhateverClass someVeryBadHackishMethod. [:a | 42]' -> true > > I need to identify whether the string is a closure or not. And ideally, I > don't want to do an #evaluate: because I don't want any left hand code to > be executed. > I tried with #parse: why I am having problems. > > Any ideas? > > > Not sure if you're still stuck but if you dive into evaluate: you'll be > able to find the point at which it parses, and find out how to invoke the > parser for an expression (a doit). evaluate: parses an expression so > you want to check that the resulting parse tree is that of a return node > whose expression is a literal block. You can also check the block's > argument count. > > Once you've extracted the parser invocation you can wrap this in a > suitable exception handler. Then you have your block parser. You still > have to validate the parse tree and/or generated code before evaluating > since someone could write malicious code within the block right? > > > Thanks in advance > > -- > Mariano > http://marianopeck.wordpress.com > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 13, 2017