- Pharo-dev - lists.pharo.org

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

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

by Frank-B

@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

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

by stephan

On 12-08-17 22:24, Frank Berger Software wrote: > the available documentation on Orca looks brilliant and the source, > Hasso-Plattner-Institut in Potsdam, has an excellent reputation. It > looks all very professional. > > I am therefore most suprised that I cannot find any tracks of usage of > Orca, neither here, nor elsewhere on the net, and not even any serious > discussions. It was indeed a well-executed bachelor project from HPI, that was submitted for the ESUG21011 InnovationTechnologyAwards. It was released under MIT at the end of the project. HPI however, is a research institute and needs to be very careful about which projects it can afford to support indefinitely. https://github.com/bp2010h1 http://esug.org/wiki/pier/Conferences/2011/InnovationTechnologyAwards/Submi… https://groups.google.com/forum/#!topic/orcaproject/ Stephan

Aug. 13, 2017

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

by Andrei Chis

On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Andrei, > > On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> >> Hi, >> >> I was executing this code '(2009/2000) ** (3958333/100000)' with the >> Pharo6.1 distribution and the vm crashed with she stack attached below. >> Tried it on both mac and windows 10. >> Seems that #raisedTo: has a special case for fractions that ends up >> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. >> > > The plugin is now fixed; see VMMaker.oscog-eem.2262. I'll generate code > soon (am debugging something you're familiar with that takes several hours > to run and don't want to generate sources while it's running). But I'm > glad you've found a better way! This case creates 600k byte large integers > and takes forever to run :-) > Nice! Thanks for the fix. Cheers, Andrei > > >> Cheers, >> Andrei >> >> >> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) >> LargePositiveInteger >> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) >> LargePositiveInteger >> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) >> LargePositiveInteger >> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) >> LargePositiveInteger >> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: >> a(n) LargePositiveInteger >> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: >> a(n) LargePositiveInteger >> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 >> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction >> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction >> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction >> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject >> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler >> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) >> RubSmalltalkEditor >> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) >> RubSmalltalkEditor >> 0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint >> 0x3062fdc8: a(n) GLMMorphicPharoScri >> enderer >> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm >> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm >> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState >> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState >> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState >> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph >> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState >> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState >> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph >> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class >> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) >> MorphicUIManager >> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > >

Aug. 13, 2017