December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Spec] Non resizable window

by StÃ©phane Ducasse

On Dec 10, 2013, at 7:49 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > Is there any simple way to make a SpecWindow not resizable? No idea but we should be able to specify that in the spec > > Cheers, > R >

Dec. 10, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by StÃ©phane Ducasse

The problem is that to see the description you will need to load all the configurations. So I think that the way to go is the following: - extend the catalog to generate a STON file with all the configuration and their descriptions - publish it in a stable url - fetch this description and display it in your tool. This would be really great. Stef On Dec 10, 2013, at 6:38 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Ok, in 12374 (incomplete, needs love) > > https://pharo.fogbugz.com/f/cases/12374/Display-package-description-on-sele… > > Cheers, > > HernÃ¡n > > > > 2013/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Hi Hernan, >> >> the problem is not the button - but the missing standard and standardized descriptions >> on the configs... >> >> For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it >> is loadable as a usual config but adds two class side methods: #documentation >> and #tutorialOn: using the <onlineTutorial> pragma. >> >> The documentation is stored as class comment in markdown format on the >> ConfigurationOfINIFile class. I use the same description then for the STHub project page. >> >> If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear >> magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks >> like nobody is really interested. > > this is not that this is a question of time. > And sorry but I will not use markdown. > >> Maybe because often this ends in "which syntax" discussions and due to the lack of >> good in image default text display facilities for markup, pier-syntax, ... >> >> In general it can be done easily, but we have to agree on some kind of "common standard" >> for configurations and documentation on >> - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar) >> - how to name the methods or pragmas that are used >> >> Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting >> methods: #catalogDescription and > > >> #repositoryUrlString. > > this one is deprecated after discussing with versioner. > >> Still Catalog uses Pier and is not really visible - and STHub does support markdown by default. >> >> As of today I would like to see Pharo moving into the following direction: >> - using the configs for describing the help/documentation/package descriptions >> - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games") >> - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated) >> - generate pages like catalog https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? >> but with a better design and visibility like "http://packages.pharo.org" > > The code is open. My time is really counted. > Just merged your convention to mine and unify. > >> together with a loadable list for the config browser >> - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the >> STHub description (which is currently only possible via the web interface) >> - additional rankings (number of downloads like on STHub, successful CI builds, member rankings, ...) >> - automated verfication >> - ... <snip>lot of other ideas</snip> >> >> Bye >> T. >> >> Gesendet: Sonntag, 08. Dezember 2013 um 22:12 Uhr >> Von: "HernÃ¡n Morales Durand" <hernan.morales(a)gmail.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser? >> Hi Torsten, >> >> 2013/12/8 Torsten Bergmann <astares(a)gmx.de> >> The reason is simple: when I wrote the config browser >> there was no such additional description on the configs itself >> and one would have to load the config into the image first. >> >> Think of 2000 config's (note each is a package) loading in the future when >> the config browser opens. This will take ages. I think this is not good >> since the app should be responsive. >> >> Maybe a "show details" button helps when the package is selected. >> >> >> >> I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits. >> >> So anyone see any workaround here? >> >> >> >> I would rather see: >> 1. Either a simple hosted seaside app "Pharo Store" that one can use to >> register a config for a specific pharo version (similar like squeakmap) >> maybe directly from the STHub interface with description, ... >> >> This app can be queried by the config browser (JSON/XML/Fuel/...) >> to display infos on the package, maybe also a rating about downloads, ... >> >> 2. Or a general mechanism that loads the configs, runs tests and if >> OK provides them for the config browser as "yes these config really work" >> >> >> Absolutely. Configurations should be certified. >> >> >> HernÃ¡n >> > >

Dec. 10, 2013

Re: [Pharo-dev] Systemtools and roadmap for pharo3

by StÃ©phane Ducasse

> Hi there, > > I have a couple of questions about Systemtools (Messagebrowser, Browser, Changesorter ...). > Is there roadmap for pharo3, on what are you working, what should work for the next release. Basically everything inheriting from CodeHolder should get rewritten. MessageBrowser was rewritten but before Spec, ChangeSorter with Spec but it should be improved. > I filed (and fixed) some bugs. And have some more. But I don't want to > do this if some of the tools may be deprecated or will be replaced. Indeed. > I read the Pharo2 and 3 changelog, but I am still unsure, and before > I make unneeded bug reports: > > There are some bugs on MessageBrowser: > Time stamp from source/byte code /time stamp-combo doesn't work. We should fix messagebrowser because it is important and may be one day we will rewrite it. > MessageBrowser doesn't play well with RGCommentDefinition as search results: > Textpanel tries to parse comments as code (this is an old bug, even recent squeak versions) > Browse senders/Implementers doesn't make sense /doesn't work for comments > Browse Version does not work for comments > No menu on comment entries. > MNU if exactly one entry is found > Some of these issues aren't new and there were already discussions > for the older FlatMessageList.(issue 5860). Yes sadly we got distracted. > Work on dualchangesorter seems to be half-done (menu-handling broken). > (no one uses dualchangesorter nowadays?) Apparently. But I use it and I started to fix the Menu of the changeSorter and I should finish then work on the DualChangeSorter but no time for that. > It distract me a bit that the completion menu *in spotlight* shows codecompletion > that *spotlight can not find* (class vars for example). > > and more. One pass should be done to improve ecompletion. Then indeed merging spotlight logic and ecompletion would be good. > I am not a total novice, but more than most of you. And so I may > stumble across some issues, that you don't encounter in your workflow. > (Otherwise I can not explain why there are no bug reports for these issues :-). Because people have different workflow. I systematically report bugs. > Am I free in reporting all kind of bugs or is this "too much noise". No if there are bugs there are. > Btw, what about Pharo2.0, is this release freezed, or can/should issues be > reported and fixed for Pharo2.0 as well? Pharo 20 is frozen. Only **severe** bugs are retro pushed. We should improve 3.0 so thanks for any bug fixes. > > regards > Nicolai >

Dec. 10, 2013

Re: [Pharo-dev] Multiples OpenGL contexts with NBOpenGL

by StÃ©phane Ducasse

JB or igor can you give access to ronie to NBOpenGL? @Ronie please publish directly to NBOpenGL no need to have a slice but update the configuration. Stef On Dec 9, 2013, at 10:07 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > <nbopengl-contexts.zip>

Dec. 10, 2013

Re: [Pharo-dev] Smalltalk in a C World

by kilon alios

I agree 100% with you, it takes like no effort to fine one of the millions of online sexy looking template and there like tons of apps out there that can autogenerate good looking websites. But then I find this much , much worse -> http://java.com/en/ . Sure it looks more current but really ? Is that the best mega-company like Oracle can do. No because as it seems this is the same site they inherited from Sun. Actually as far I remember Java from back into 2000 that I was aware of its existence , the website has only slightly changed. Actually I know of no language that has a very well designed web site. Taking full advantage of HMTL5 and the current technology. But I like Pharo website none the less. Java Hyped !!! What ? Are you serious ? Java - C++ - Javascript is the triangle of hate. Back in 2000 + was an army of blog posts of how dead Java is and still you can see articles of how much people dont like these languages. Not that I blame them , but I always kinda liked Java. Hype is not the same thing as popular. I think the most Hyped language by far is Lisp , nothing can touch its hype. You could even believe that Lisp can cure cancer. I really like Lisp, but its over-hyped none the less. I had to try lisp because of how much overwhelmed I was by people saying how much of a great language it is. Learning Java was curiosity on the ground how popular it became and how fast. I never heard anyone describe Java as Lisp. Actually the most hyped thing about Java is Clojure, guess what Clojure is , yeap Lisp :D "But Smalltalk is (at least to me) not interesting because it is a programming language - it is interesting because it is a dynamic object system that is easily changeable (including metamodel and language itself)." I could not agree more. I came for the IDE, I feel in love with live coding. Beatiful, makes coding 10 times more fun and very productive. But I have to say Smalltalk really does justice to its name. Its a Small language but also everything feels like you Talk-ing to objects, I really like this conversation with my computer , If I could remove case sensitive it would be 100% natural for me. So yes definetly there is not much in the language to be surprised about but in the end that element of least surprise is what make Smalltalk a great choice for me. On Mon, Dec 9, 2013 at 1:46 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 09 Dec 2013, at 11:37, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Kilon wrote: > >> dlls alone wont be enough , plugins are compiled against a runtime or > specific libraries (a Plugin SDK) and Smalltalk MT > >> would have to be able to do that in order to be a viable solution. > > > > You can be sure it can :) > > > > Clement wrote: > >> How can people even know Smalltalk MT still exist with their website and > >> their communication ? > > > > If you follow the hype and advertising you go to Java - if you search > > for something more powerful you search for it and will find Smalltalk. > > > You search and you find a website that convinces you that Smalltalk it > indeed > dead. > > Marcus > > >

Dec. 10, 2013

[Spec] Non resizable window

by Roberto Minelli

Hi, Is there any simple way to make a SpecWindow not resizable? Cheers, R

Dec. 10, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by HernÃ¡n Morales Durand

Ok, in 12374 (incomplete, needs love) https://pharo.fogbugz.com/f/cases/12374/Display-package-description-on-sele… Cheers, HernÃ¡n 2013/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > Hi Hernan, > > the problem is not the button - but the missing standard and standardized > descriptions > on the configs... > > For instance I also write markup docu on my configs (see > ConfigurationOfINIFile) - it > is loadable as a usual config but adds two class side methods: > #documentation > and #tutorialOn: using the <onlineTutorial> pragma. > > The documentation is stored as class comment in markdown format on the > ConfigurationOfINIFile class. I use the same description then for the > STHub project page. > > If one loads additionally the "PharoOnlineHelp" package afterwards it will > also appear > magically in my Pharo online help as a tutorial. This was my proposal - > but so far it looks > like nobody is really interested. > > > this is not that this is a question of time. > And sorry but I will not use markdown. > > Maybe because often this ends in "which syntax" discussions and due to > the lack of > good in image default text display facilities for markup, pier-syntax, ... > > In general it can be done easily, but we have to agree on some kind of "common > standard" > for configurations and documentation on > - how to describe a package (also the format, either markdown or pier > syntax with http://smalltalkhub.com/#!/~Pier/Pillar<https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Fsmalltal…> > ) > - how to name the methods or pragmas that are used > > > Stef also did something (with Catalog), the ConfigurationOfINIFile for > instance has two supporting > methods: #catalogDescription and > > > > #repositoryUrlString. > > this one is deprecated after discussing with versioner. > > Still Catalog uses Pier and is not really visible - and STHub does support > markdown by default. > > As of today I would like to see Pharo moving into the following direction: > - using the configs for describing the help/documentation/package > descriptions > - also tagging with package categories (for instance there are > packages/projects for "database access", others for "parsers", or "games") > - maybe use pier syntax for descriptions (it can be parsed by Pillar and > other formats like HTML, markdown, Latex, ... be generated) > - generate pages like catalog > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? > but with a better design and visibility like " > http://packages.pharo.org" > > > The code is open. My time is really counted. > Just merged your convention to mine and unify. > > together with a loadable list for the config browser > - when one uploads such a ConfigurationOfMyKillerApp to STHub it should > automagically update the > STHub description (which is currently only possible via the web > interface) > - additional rankings (number of downloads like on STHub, successful CI > builds, member rankings, ...) > - automated verfication > - ... <snip>lot of other ideas</snip> > > Bye > T. > > *Gesendet:* Sonntag, 08. Dezember 2013 um 22:12 Uhr > *Von:* "HernÃ¡n Morales Durand" <hernan.morales(a)gmail.com> > *An:* "Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] It would be too expensive to add a description > for packages in Configuration Browser? > Hi Torsten, > > 2013/12/8 Torsten Bergmann <astares(a)gmx.de> >> >> The reason is simple: when I wrote the config browser >> there was no such additional description on the configs itself >> and one would have to load the config into the image first. >> >> Think of 2000 config's (note each is a package) loading in the future when >> the config browser opens. This will take ages. I think this is not good >> since the app should be responsive. >> >> Maybe a "show details" button helps when the package is selected. >> > > > > I agree (see attached screenshot). I have added the button but the thing > is: Package can be fetched from the repository, but there is no package > description. There are only textual descriptions of commits. > > So anyone see any workaround here? > > > >> >> I would rather see: >> 1. Either a simple hosted seaside app "Pharo Store" that one can use to >> register a config for a specific pharo version (similar like >> squeakmap) >> maybe directly from the STHub interface with description, ... >> >> This app can be queried by the config browser (JSON/XML/Fuel/...) >> to display infos on the package, maybe also a rating about downloads, >> ... >> >> 2. Or a general mechanism that loads the configs, runs tests and if >> OK provides them for the config browser as "yes these config really >> work" >> > > > Absolutely. Configurations should be certified. > > > HernÃ¡n > > > >

Dec. 10, 2013

Systemtools and roadmap for pharo3

by Nicolai Hess

Hi there, I have a couple of questions about Systemtools (Messagebrowser, Browser, Changesorter ...). Is there roadmap for pharo3, on what are you working, what should work for the next release. I filed (and fixed) some bugs. And have some more. But I don't want to do this if some of the tools may be deprecated or will be replaced. I read the Pharo2 and 3 changelog, but I am still unsure, and before I make unneeded bug reports: There are some bugs on MessageBrowser: Time stamp from source/byte code /time stamp-combo doesn't work. MessageBrowser doesn't play well with RGCommentDefinition as search results: Textpanel tries to parse comments as code (this is an old bug, even recent squeak versions) Browse senders/Implementers doesn't make sense /doesn't work for comments Browse Version does not work for comments No menu on comment entries. MNU if exactly one entry is found Some of these issues aren't new and there were already discussions for the older FlatMessageList.(issue 5860<https://pharo.fogbugz.com/default.asp?5860>). Work on dualchangesorter seems to be half-done (menu-handling broken). (no one uses dualchangesorter nowadays?) It distract me a bit that the completion menu *in spotlight* shows codecompletion that *spotlight can not find* (class vars for example). and more. I am not a total novice, but more than most of you. And so I may stumble across some issues, that you don't encounter in your workflow. (Otherwise I can not explain why there are no bug reports for these issues :-). Am I free in reporting all kind of bugs or is this "too much noise". Btw, what about Pharo2.0, is this release freezed, or can/should issues be reported and fixed for Pharo2.0 as well? regards Nicolai

Dec. 9, 2013

Re: [Pharo-dev] Smalltalk in a C World[SEC=UNCLASSIFIED]

by Stephen Taylor

On Mon, 2013-12-09 at 11:37 +0100, Torsten Bergmann wrote: > If you follow the hype and advertising you go to Java - if you search > for something more powerful you search for it and will find Smalltalk. That's no way to think! Smalltalk is wonderful, but it gains nothing by being obscure and largely forgotten. Whenever people are fans of something arcane there's a temptation for them to wear that obscurity like a medal. And it does no good. No good at all. Steve

Dec. 9, 2013

Re: [Pharo-dev] Smalltalk in a C World

by phil＠highoctane.be

Now, moving forward, what would be required to have an interpreter embedded in C, even if this means having another image with a special API and the whole enchilada? At least a working prototype. I have looked at the "Porting the VM" document and the part about headless (which is now done differently). What comes to my mind is to define a specific neutral C platform that would be able to execute basic bytecode. >From videos of Ben, I saw SystemTracer (or SystemTracer2) recreating a very tiny image making some noise to prove it was working. Could it be possible to target this kind of tiny image running inside a C program through a base interpreter? This would avoid having to deal with the whole primitives and plugins at the beginning. Phil On Mon, Dec 9, 2013 at 9:07 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > The main issue is that it is complicated to embed the VM in C code. > That's due to how the VM is done. > > Compared to TCL, where you can easily embed the interpreter in a C > program, this is a problem. http://wiki.tcl.tk/3474 > > Where you can embed the interpreter in a C program, you can do whatever > integration you want. > > Now, with NativeBoost, we can call C. The next challenge would be to be > able to call Pharo from C by embedding the interpreter. > > I am curious to see what you guys think about this. > > > It is one of my dream! > Now I'm too bad in C to make this dream comes true. Sadly. But I would > love to have Pharo being able to > be embedded in C. > > > I would love to see things like mod_pharo (as there is mod_php, mod_perl, > mod_tcl...) in Apache. > > > > > > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value > Added Reseller > > > > > On Mon, Dec 9, 2013 at 9:48 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> please note that generating dlls alone wont be enough , plugins are >> compiled against a runtime or specific libraries (a Plugin SDK) and >> Smalltalk MT would have to be able to do that in order to be a viable >> solution. >> >> >> On Mon, Dec 9, 2013 at 10:28 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> You should think that they use their smalltalk for their projects. >>> >>> Stef >>> >>> On Dec 9, 2013, at 9:21 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> How can people even know Smalltalk MT still exist with their website and >>> their communication ? >>> >>> I looked at other Smalltalks a while ago, for Smalltalk MT I clicked on >>> "what's new" on their website and I got that: >>> >>> <Screen Shot 2013-12-09 at 9.18.11 AM.png> >>> >>> Then I thought this Smalltalk was dead (nothing new in the past 4 years) >>> and I didn't look any further. >>> >>> >>> 2013/12/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>>> >>>> > Yes - still alive and kicking. But I'm sure you did not notice since >>>> there >>>> > are no "big" announcements or advertising for it. >>>> > ObjectConnect follows the "time is better invested into technology" >>>> strategy. >>>> > It is one of the most interesting Smalltalks ever implemented. >>>> >>>> http://www.objectconnect.com/stmt_overview.htm >>>> I like the idea that you can get 50kb applications. >>>> Now since this is a closed system and windows-centric. >>>> But I like that it shows that Smalltalk does not have to be the image >>>> centric way. >>>> >>>> > >>>> > The newest ST/MT 6.3 version (now 64 bit) is from end of November 2013 >>>> >>>> Now it is not a community thing. :) >>>> And the web site stop and 5.6 in 2009. >>>> >>>> Last time I talk to tarrick he told me that he could control the "no gc >>>> in the next 250 frames on PS2" >>>> but it was in 1998 :) >>>> >>>> >>>> Stef >>>> >>> >>> >>> >> > >

Dec. 9, 2013