June 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] MorphTree behavior changed

by Hilaire Fernandes

Just confused by the shift to Annoucement. Ok now. Again I beg for consolidations in Pharo to avoid confusion with multiple frameworks doing the same things. Hilaire Le 06/06/2014 11:08, Tudor Girba a Ã©crit : > Hi Hilaire, > > Could you be more specific? > > What exactly is the problem? > > Cheers, > Doru > > > > > On Tue, Jun 3, 2014 at 8:24 PM, Hilaire Fernandes > <hilaire.fernandes(a)gmail.com > <mailto:hilaire.fernandes@gmail.com>> wrote: > > Hi, > > why when morph tree send updateList there is an announcement from the > model? It was not the case before. > > Thanks > > Hilaire > > -- > Dr. Geo http://drgeo.eu > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" -- Dr. Geo http://drgeo.eu

June 6, 2014

Re: [Pharo-users] Slowness question

by Hilaire Fernandes

I did not try yet. Hilaire Le 05/06/2014 19:46, Alain Busser a Ã©crit : > What does the profiler say? > > Alain > -- Dr. Geo http://drgeo.eu

June 6, 2014

Re: [Pharo-users] MorphTree behavior changed

by Tudor Girba

Hi Hilaire, Could you be more specific? What exactly is the problem? Cheers, Doru On Tue, Jun 3, 2014 at 8:24 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Hi, > > why when morph tree send updateList there is an announcement from the > model? It was not the case before. > > Thanks > > Hilaire > > -- > Dr. Geo http://drgeo.eu > > > -- www.tudorgirba.com "Every thing has its own flow"

June 6, 2014

Re: [Pharo-users] Slowness question

by Alain Busser

What does the profiler say? Alain On Thu, Jun 5, 2014 at 1:15 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Hi, > > > Programmed sketch in DrGeo can be animated, for example like the script > bellow. > The "canvas do:" message forks the block so user is not blocked. > At #udpate message the items and views (morph) are recomputed and refreshed > . > Before porting DrGeo to Athens, the animation was pretty fast, now it is > very slow. > > Any idea from where it could come from? > > Thanks > > > ---8<------ > |canvas s stats points| > > points :=Array new: 12. > stats := Array new: 12 withAll: 0. > > canvas := DrGeoCanvas new. > 2 to: 12 do: [:i | > points at: i put: (canvas point: i(a)0.1) > (points at: i) square; color: Color blue. > s := canvas segment: i@0 to: (points at: i). > s color: Color red]. > > canvas do: [ > 1 to: 10000 do: [:i| > s := 6 atRandom + 6 atRandom. > stats at: s put: ((stats at: s)+1). > (points at: s) > name: (stats at: s) asString; > moveTo: s @ ((stats at: s) / 100). > canvas update]. > ---8<------ > > > > -- > Dr. Geo http://drgeo.eu > > >

June 5, 2014

Re: [Pharo-users] PIllar >> #visitAnnotatedParagraph:

by Damien Cassou

On Tue, Jun 3, 2014 at 6:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > I've uploaded the updates to make annotations more consistent, and added the > \dothis LaTeX command being used in the PharoLaserGame tutorial. > > source > annotation test > # item 1 > @@note anno1 > @@dothis anno2 > ## item 11 > @@note anno3 > ## item 12 > @@dothis anno4 > ## item 13 > > --to=pillar > annotation test > # item 1 > @@note anno1 > @@dothis anno2 > # > ## item 11 > @@note anno3 > # > ## item 12 > @@dothis anno4 > # > ## item 13 > Now this output is not the same and the source. Should I try to fix this the > same as I did for comments. please. It is important to keep consistency here. > --to=html > <div class="container"> > annotation test > <ol><li> item 1 </li></ol> > anno1 > anno2 > <ol><li> <ol><li> item 11 </li></ol> </li></ol> > anno3 > <ol><li> <ol><li> item 12 </li></ol> </li></ol> > anno4 > <ol><li> <ol><li> item 13 </li></ol></li></ol> > </div> > > --to=markdown > annotation test > 1. item 1 > ^M ^M > anno1^M ^M > anno2^M ^M > 1. > 1. item 11 > ^M ^M > anno3^M ^M > 1. > 1. item 12 > ^M ^M > anno4^M ^M > 1. > 1. item 13 > btw, what are all these non-break-spaces "^M ^M" for? no idea. Ben, do you have an idea? You did a great job. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 5, 2014

Re: [Pharo-users] Xcode's Swift Playground

by ClÃ©ment Bera

2014-06-04 11:33 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 03 Jun 2014, at 6:32 , Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> > wrote: > > To what I understand, types are inferred, it is not statically typed. Am I > wrong ? > > > If there is type inference then it is statically typed (at least partially > if not every variable type can be inferred) > > > To repeat myself: this is not the case. Example is the RoelTyper. > > > Yes, there are many type inferencers for dynamically-typed languages. > But that's not because one builds a type inferencer for say Smalltalk that > I can say "Smalltalk has type inference": the inferencer is not integrated > within the language, it's just an analysis tool on top. > If someone says that his language has type inference, he means that the > type inferencer is built into the language, and normally there is some type > checking and/or the compiler is designed to leverage type information which > means that the language is at least partially statically-typed (if not > entirely). > Because if a language does no type checking nor type-based optimisations, > for what purpose would it have type inference built into it? > > > Inferred types have an often overlooked purpose that, IMHO, in dynamic > languages, is their biggest benefit. > That being, it can reduce the number of false positives in common > development actions such as auto-complete, searching for implementors, etc. > > A pharo with built-in type inference would be no better. > A pharo with built-in type inference, and tools utilizing it, would. > > Itâs a bit of a shame that programmer productivity is a less favourable > research area than optimization, when in that case, using the much cheaper > type info from PICâs instead, yield equivalent results. > (ref. http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla95-tf.pdf) > > This is actually possible in Pharo. If you compile the Cog VM with the Sista Cogit, you have then in addition the introspection primitive that returns branch and send data from native code methods. Now you cannot use these inferred types for tools. There are 3 main issues, one is that the VM answers you concrete types and not an abstract type, the second is that not all message sends have type information (the method may not be linked to a native code method, the message send may not have been used since the native code method has been compiled and megamorphic send sites have no type information) and the last issue is that the type inferred are common types, if you can use another type in an uncommon case you may not see it. - you needs a type inferencer for tools. - you need type information from the inline caches for optimizations. And as proven in the early 90s type inferencer does not work well to optimize dynamic object oriented language and type-feedback does not work well for tools as I explained. Clement Cheers, > Henry >

June 5, 2014

Re: [Pharo-users] Slowness question

by ClÃ©ment Bera

Igor do you have a clue ? (I'm not sure Igor is on pharo-users) Clement 2014-06-04 23:15 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Hi, > > > Programmed sketch in DrGeo can be animated, for example like the script > bellow. > The "canvas do:" message forks the block so user is not blocked. > At #udpate message the items and views (morph) are recomputed and refreshed > . > Before porting DrGeo to Athens, the animation was pretty fast, now it is > very slow. > > Any idea from where it could come from? > > Thanks > > > ---8<------ > |canvas s stats points| > > points :=Array new: 12. > stats := Array new: 12 withAll: 0. > > canvas := DrGeoCanvas new. > 2 to: 12 do: [:i | > points at: i put: (canvas point: i(a)0.1) > (points at: i) square; color: Color blue. > s := canvas segment: i@0 to: (points at: i). > s color: Color red]. > > canvas do: [ > 1 to: 10000 do: [:i| > s := 6 atRandom + 6 atRandom. > stats at: s put: ((stats at: s)+1). > (points at: s) > name: (stats at: s) asString; > moveTo: s @ ((stats at: s) / 100). > canvas update]. > ---8<------ > > > > -- > Dr. Geo http://drgeo.eu > > >

June 5, 2014

Re: [Pharo-users] Xcode's Swift Playground

by S Krish

+100 I love this playground. Will explore it sometime.. and see if I can participate first in building tools for use and then dive into its frameworks ..! To get started I will need to have a minimum of Oracle connection rather than PostGres .. to make it worthwhile as I play with it. Any heads up on that is nice.. On Tue, Jun 3, 2014 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The work on GToolkit goes in this direction. Funny enough, we also have a > Playground :). > > Look here for an example: > > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > > More will come in this direction. I happen to believe that this is the > area with the largest potential in Pharo, and it would be great to put more > effort around it. If people have an interest to participate, please just > let me know. > > Cheers, > Doru > > > > On Tue, Jun 3, 2014 at 9:02 AM, darrinm <darrin(a)massena.com> wrote: > >> Here's an example of the Playground in use: >> >> https://developer.apple.com/library/prerelease/ios/recipes/xcode_help-sourc… >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Xcode-s-Swift-Playground-tp4761425p4761431.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 5, 2014

Slowness question

by Hilaire Fernandes

Hi, Programmed sketch in DrGeo can be animated, for example like the script bellow. The "canvas do:" message forks the block so user is not blocked. At #udpate message the items and views (morph) are recomputed and refreshed . Before porting DrGeo to Athens, the animation was pretty fast, now it is very slow. Any idea from where it could come from? Thanks ---8<------ |canvas s stats points| points :=Array new: 12. stats := Array new: 12 withAll: 0. canvas := DrGeoCanvas new. 2 to: 12 do: [:i | points at: i put: (canvas point: i(a)0.1) (points at: i) square; color: Color blue. s := canvas segment: i@0 to: (points at: i). s color: Color red]. canvas do: [ 1 to: 10000 do: [:i| s := 6 atRandom + 6 atRandom. stats at: s put: ((stats at: s)+1). (points at: s) name: (stats at: s) asString; moveTo: s @ ((stats at: s) / 100). canvas update]. ---8<------ -- Dr. Geo http://drgeo.eu

June 4, 2014

Re: [Pharo-users] Saving Seaside components to Monticello

by Sven Van Caekenberghe

On 04 Jun 2014, at 21:47, phil(a)highoctane.be wrote: > > Le 4 juin 2014 21:17, "spearson" <sam(a)xofz.com> a Ã©crit : > > > > Hello, > > I created a Monticello repository on Smalltalkhub. When I commit my > > package, my Object subclasses all get saved to the repository. However, > > only my WAComponent subclass class definition gets saved (instance/class > > variables). The renderContentOn: and updateRoot: methods are not getting > > saved to the repository. Is this because they are overridden methods and > > not new methods? > > > > How can I save my renderContentOn: and updateRoot: methods to the > > repository? > > > > > > Strange. Never had this issue with Seaside. I don't think this is a Seaside problem. Did you follow any tutorial concerning the practical use of Monticello ? In any case, we need more details, maybe a screenshot or two. > Phil > > > > -- > > View this message in context: http://forum.world.st/Saving-Seaside-components-to-Monticello-tp4761679.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > >

June 4, 2014