- Pharo-dev - lists.pharo.org

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

by phil＠highoctane.be

I was more about primitives doing things with I/O. On Tue, Dec 10, 2013 at 9:50 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Dec 9, 2013, at 10:45 PM, phil(a)highoctane.be wrote: > > > 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. > > Guille continued and we are working to use his bootstrap as a basis for > 4.0. > Now you will need the key primitives such as become: at: at:put: and other. > > Stef >

Dec. 10, 2013

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

by StÃ©phane Ducasse

On Dec 9, 2013, at 10:45 PM, phil(a)highoctane.be wrote: > 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. Guille continued and we are working to use his bootstrap as a basis for 4.0. Now you will need the key primitives such as become: at: at:put: and other. Stef

Dec. 10, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30634 Home: https://github.com/pharo-project/pharo-core

Dec. 10, 2013

[pharo-project/pharo-core] 6a1e6f: 30634

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 6a1e6f5c48d0cb93a2a1edb7b4c4aac40f589e0e https://github.com/pharo-project/pharo-core/commit/6a1e6f5c48d0cb93a2a1edb7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-10 (Tue, 10 Dec 2013) Changed paths: A Komitter.package/DataRetriever.class/README.md A Komitter.package/DataRetriever.class/class/instance creation/for_.st A Komitter.package/DataRetriever.class/definition.st A Komitter.package/DataRetriever.class/instance/accessing/block_.st A Komitter.package/DataRetriever.class/instance/accessing/data.st A Komitter.package/DataRetriever.class/instance/accessing/nullObject_.st A Komitter.package/DataRetriever.class/instance/initialize/initialize.st A Komitter.package/DataRetriever.class/instance/private/retrieveData.st A Komitter.package/DataRetriever.class/instance/private/signalDataIsReady.st A Komitter.package/DataRetriever.class/instance/protocol/release.st M Komitter.package/KomitPackage.class/definition.st M Komitter.package/KomitPackage.class/instance/accessing/patch.st M Komitter.package/KomitPackage.class/instance/initialize/initialize.st R Komitter.package/KomitPackage.class/instance/private/resetFork.st M Komitter.package/KomitPackage.class/instance/private/retrievePatch.st R Komitter.package/KomitPackage.class/instance/private/signalPatchIsReady.st M Komitter.package/KomitPackage.class/instance/protocol/flush.st M Komitter.package/KomitSliceUI.class/instance/initialization/initializeDialogWindow_.st M Komitter.package/KomitterUI.class/instance/initialization/initializeDialogWindow_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script289.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30634.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicButtonAdapter.class/class/specs/defaultSpec.st M Tools.package/FinderUI.class/instance/t - accessing/menu_shifted_.st Log Message: ----------- 30634 12376 Finder raises an error when right clicking on the main panel https://pharo.fogbugz.com/f/cases/12376 12380 The logic to retrieve the patch of KomitPackage should be extracted https://pharo.fogbugz.com/f/cases/12380 12378 On Unix, the shortcut to validate the Komitter window is not working https://pharo.fogbugz.com/f/cases/12378 12375 PluggableButtonMorph error on getMenuSelector https://pharo.fogbugz.com/f/cases/12375 http://files.pharo.org/image/30/30634.zip

Dec. 10, 2013

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

by phil＠highoctane.be

I did a ton of Java (coding, training people, large scale deployments) and Java has enterprise grade features. For large apps/clients, not much can beat it these days. If you need to staff a team for a sizeable project, not much choice either. Things like this: http://ec.europa.eu/dgs/informatics/procurement/calls_running/index_en.htm where you see things like in this page ( http://ted.europa.eu/udl?uri=TED:NOTICE:380314-2013:TEXT:EN:HTML) : II.2.1) Total quantity or scope: 9 600 person-years (indicative, non-binding) for all lots for the maximum possible duration of the framework contracts. I guess there are not enough Pharo-aware people on the planet to fit this :-) There, the choice is going to be Java. Now, except when working with decent tools like Jetbrains' IntelliJ (don't get me started with Eclipse), it is really annoying to type. I am even a reseller of these products FWIW. Other than that it is a fine language. And cool people do cool things with it, like AOT (Ahead of Time) compilers. http://www.excelsior-usa.com/jet.html or the JRockitVM (from the ashes of BEA) http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html If we could get an instrumented VM like that, well... For manifesting ideas out of my head, I do prefer Pharo. As a self-employed individual, more power to me. As a startup junkie, more power to me. If I need a Java or .NET guy, I've plenty of contacts in cheap countries who do work very very well. And f*ck Ruby on Rails. Now, I said it. As I am currently reading Andres Valloud books, and trying out the exercises, man, what do I know about how to make decent enough code. Close to nothing it seems. That is what is great in Pharo, a community of great minds. That you do not find often in a huge crowd as the chatter is too loud. </rant> Phil

Dec. 10, 2013

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

by Roberto Minelli

On Dec 10, 2013, at 8:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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 +1 ;-) > >> >> Cheers, >> R >> > >

Dec. 10, 2013

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