April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

Ok so this is the way to go for me. At least to try. Le 22/4/15 21:47, Thierry Goubier a Ã©crit : > In fact, we do. Apart of the github/bitbucket kind of stuff, it is > also possible to use smalltalkhub in that way. > > It's just a matter of organizing your projects and branches (with one > smalltalkhub repository per branch). If you organize yourself that > way, you'll end up being very close to a git / branch type of approach. > > Thierry

April 23, 2015

Re: [Pharo-dev] ARM Cogit

by stepharo

This is really excellent! Keep pushing this. I'm eager to play with a raspberry. We should continue to revisit the UI elements to consume less in any case. Because I'm convinced that we are doing too many things at the wrong place. Stef Le 22/4/15 21:42, Eliot Miranda a Ã©crit : > Hi All, > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have > a functional JIT for the ARM in the simulator. We're still probably > some weeks away from a functional ARM JIT VM; issues like instruction > cache flushing on real hardware can be tricky to solve. But we're at > least ready to start trying to compile the JIT VM for ARM. Doug, see > that I added a build directory for build.linux32ARM/squeak.cog.spur. > Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. > -- > best, > Eliot

April 23, 2015

Re: [Pharo-dev] Improving the documentation model

by Kasper Osterbye

To me this whole notion of which format to use, if it should be WYSIWYG, and what kind of markup to use is somewhat dependent on that usage scenarios one consider. I too would like to see something which moves beyond plain strings. As the computer scientist I am, would also like it to be something uniform across usage. However - there is difference in how we I view a comment and how I view a book. In a method comment I would like to be able to add a little bold, and perhaps a few links to elsewhere. In a class method I would like to be to also do lists, perhaps a heading or two (which I could do with bold perhaps). A package comment I start to want to include diagrams and images. In a full book or paper, well, I want it all there (aka level of Latex or Word). Pillar is no worse than 99% of the other markup's out there, so fine with me. What I tried in my little Pillar/Nautilus combo was to show how one can make a morph which shows pillar markup as a rendered text (as opposed to string), but editing that text is done by editing the pillar markup. I believe someone with more experience than I can make one that works more smoothly. Also, I believe the same trick can be used of inlined method comments. So, my point is, that Pillar and other markup languages were intended to be for wiki, and web pages, not for books. That is something at the level of class comments or package comments. -- View this message in context: http://forum.world.st/Improving-the-documentation-model-tp4820814p4821286.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2015

Re: [Pharo-dev] ARM Cogit

by kilon alios

Yes , yes , yesssss , would love to have Pharo available on Android and use it on my smartphone on a daily basis , thank you very much guys. On Wed, Apr 22, 2015 at 9:42 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have a > functional JIT for the ARM in the simulator. We're still probably some > weeks away from a functional ARM JIT VM; issues like instruction cache > flushing on real hardware can be tricky to solve. But we're at least ready > to start trying to compile the JIT VM for ARM. Doug, see that I added a > build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM > for Raspberry Pi and Android is only a few weeks away. > > -- > best, > Eliot >

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by kilon alios

There is a solution that I was thinking when I was imagining implementing my own Configuration Browser than I named "Tartara". One of the ideas I had was the introduction of packages, which is basically something that would trigger the installation of multiple projects at the same time. So I was imaging "Core" package that will contain all the core IDEs, "GT" package all the GT tools , "Games" where there will be multiple games etc. This way the user would not need to install those tools one by one. Ideally I was also imagining a detailed description per package with even the ability to rate the quality of the package or even review it . >From the looks of it this is already possible with Configuration Browser but it does not provide this separation yet. On Wed, Apr 22, 2015 at 11:18 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote > > NO NO NO integration in the image. > > NO external tools to talk to. NO NO NO Change your mindset. > > I was actually thinking specifically of new users. I already know how to > load it and make extensive use of startup preferences so it doesn't really > matter to me. But it's taken me 5 years to find all the cool extensions I > use routinely. How will a new user appreciate our Ferrari when we give it > to > them without paint, headlights, or seats? Maybe we can have something like > Edgar's FunSqueak, with all the cool IDE features, be the default download, > but then, if we're not all using that image, we may commit a sin similar > Marcus' repeated warning that "the artefact on the build server needs to be > the artefact of release" of using a different image than we release... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821265.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 22, 2015

SqueakSSL plugin v0.2.0 (was: Re: Fixes to the SqueakSSL Plugin)

by Das.Linux＠gmx.de

Dear Smalltalkers as a follow up to the SqueakSSL changes sent around yesterdayâ¦ On 21.04.2015, at 16:52, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Dear Smalltalkers > > Starting with Levente Uzonyi's patches to the Linux version > of the SqueakSSL-Plugin, we (Marcel Taeumel and me) have > ported this to the OS X and Windows version as well. > > Find three binaries[1] that can be used instead of > the ones found on versions found on SqueakSSL's google code > page. > [â¦] > [1]: http://forum.world.st/file/n4820846/squeakssl.zip â¦ I'd like to thank Levente Uzonyi and Ron Teitelbaum for their input and providing infrastructure. I put together all files and have uploaded them to the new (in the googlecode-export sense) SqueakSSL gitHub project: https://github.com/itsmeront/squeakssl/ And tagged a release as v0.2.0 with a Zip of all binaries (linux32/64,osx,windows) https://github.com/itsmeront/squeakssl/releases/tag/v0.2.0 (scroll to bottom for the binaries zip: squeakssl_v0.2.0.zip) I hope this comes in handy for anyone who wants to play around with that. Best -Tobias

April 22, 2015

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

by Tudor Girba

Aha. We have the same issue with GT, so when building the development image, we first explicitly load all latest versions of ConfigurationOfG* from the project configuration. This should solve that problem. Doru On Wed, Apr 22, 2015 at 8:13 PM, stepharo <stepharo(a)free.fr> wrote: > From what I know: > the configruation of OSWindow in the repo is not loaded when there is a > configuration in the image. > Kind of > > Le 22/4/15 08:31, Tudor Girba a Ã©crit : > > Could JB describe the problem with Metacello? Perhaps there is a > workaround. > > Doru > > On Tue, Apr 21, 2015 at 3:27 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> Hi phil >>>> >>>> just that you know what we are doing >>>> >>>> - Mathieu Lacatou an intern from Thales should be visiting the >>>> team for >>>> 10 days to pair program with esteban >>>> about the OSWindow multi-windowing support >>>> >>>> - JB and Merwan are extending the OSWindow touch support, like >>>> generating scroll events >>>> >>>> - JB is working on Woden and adding some shadders for 3D demoes. >>>> >>> I will have a new guy from Senegal starting to work tomorrow in my lab >>> on using GPU and Wooden for doing SPH&epidemiological modeling. >>> How to coordinate all these activities ? >>> >> >> Cool :) >> I do not know >> For now he should have a look at Woden, JB planned to make a CI. >> But he was blocked because of a bug in the old version of Metacello that >> we use. >> So as soon as Metacello is updated, JB can continue his build. >> >> Stef >> >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by Sean P. DeNigris

stepharo wrote > NO NO NO integration in the image. > NO external tools to talk to. NO NO NO Change your mindset. I was actually thinking specifically of new users. I already know how to load it and make extensive use of startup preferences so it doesn't really matter to me. But it's taken me 5 years to find all the cool extensions I use routinely. How will a new user appreciate our Ferrari when we give it to them without paint, headlights, or seats? Maybe we can have something like Edgar's FunSqueak, with all the cool IDE features, be the default download, but then, if we're not all using that image, we may commit a sin similar Marcus' repeated warning that "the artefact on the build server needs to be the artefact of release" of using a different image than we release... ----- Cheers, Sean -- View this message in context: http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821265.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Esteban Lorenzano

> On 22 Apr 2015, at 21:17, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Wed, Apr 22, 2015 at 7:55 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > andrei > > You talk about releasing. > I talk about changes that should be done on a system while people are not active. > > If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of > packages then I see no problem if you make a slice and notify us so we can back port it. > > What I would like to avoid is this becoming the default behaviour any time you want to make change that is > just related to a project that is maintain by configurations. > > Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version > using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then > working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts > when we are actively working on rubric but then we are around to help with the merge. I will add a âcommit new versionâ option that will reduce the steps too. It will: - commit dirty packages from version to corresponding configuration, - generate and commit new version. - It will do it recursively with nested configurations so, this will solve all complains you might have :) Esteban > > Cheers, > Andrei > > > > Stef > > > Le 22/4/15 15:29, Andrei Chis a Ã©crit : >> In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). >> This allows for very simple configurations with clear dependencies. >> Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity. >> >> Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. >> I would still like to have different configurations for Glamour and Rubric as they are separate projects. >> So we can have just three configurations (each one for a separate project that can be released independent of the others): >> >> ConfigurationOfGToolkitCore >> ----> ConfigurationOfGlamourCore >> ---------> ConfigurationOfRubric >> >> This would make releasing a new version easier with the current support from versioner. >> Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case. >> >> Cheers, >> Andrei >> >> >> On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> exactly. >> what we need in the long term is a complete better integration process. >> I dream to have a git pharo project with submodules and pull requests. >> >> Slowly the tools are coming, but this will take time to implement. >> In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. >> Even if they look not easy because we are still building it, or too used to previous ways of doing it. >> >> Esteban >> >> > On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> > >> > And do not forget that with better Pharo modularization it will start >> > to be a problem on more lower level. When eg. Morphic will be an >> > "exteranal" Pharo package. >> > >> > -- Pavel >> > >> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >> >> >> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> >> >> But this only works for releasing simple configurations that do not depend >> >> on other configurations. >> >> This would work for rubric, for example, but not for other configurations we >> >> have in gtools. >> >> >> >> >> >> then you have two options: >> >> >> >> 1) you rewrite your configurations to not need nested configurations. This >> >> is not recommendable in huge projects like Seaside, but things like GTools >> >> are easily (I did a quick check and your 3 configurations have in total 7 >> >> packagesâ¦ would not be a problem to have them without nesting projects and >> >> just using the packages). In fact, this is how Dale recommends using >> >> configurations (if I understood him right). >> >> 2) we enhance the tools to also allow the commit of nested packages. >> >> >> >> I think both approaches needs to be done: you donât need unnecessary >> >> complexity in your configurations and we need to add some nesting support to >> >> commit new version. >> >> >> >> What is not admisible, IMO, is to do something that is wrong just because it >> >> looks easier in the short term (and I say âin short termâ because what looks >> >> easier now will generate a lot of problems in the future). >> >> >> >> cheers, >> >> Esteban >> > >> >> >> > >

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Andrei Chis

On Wed, Apr 22, 2015 at 7:55 PM, stepharo <stepharo(a)free.fr> wrote: > andrei > > You talk about releasing. > I talk about changes that should be done on a system while people are not > active. > If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of packages then I see no problem if you make a slice and notify us so we can back port it. What I would like to avoid is this becoming the default behaviour any time you want to make change that is just related to a project that is maintain by configurations. Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts when we are actively working on rubric but then we are around to help with the merge. Cheers, Andrei > > Stef > > > Le 22/4/15 15:29, Andrei Chis a Ã©crit : > > In all new tools that we did we tried to have only 2-3 packages and use > tags to organize classes in a packaged (GT-* has 9 packages for 3 > projects). > This allows for very simple configurations with clear dependencies. > Glamour has more packages (17) but those should also be reduced, as we do > not need such a low level of granularity. > > Given that support for working with multiple nested configuration is not > great we can merge all GT-* projects into one configuration. > I would still like to have different configurations for Glamour and Rubric > as they are separate projects. > So we can have just three configurations (each one for a separate project > that can be released independent of the others): > > ConfigurationOfGToolkitCore > ----> ConfigurationOfGlamourCore > ---------> ConfigurationOfRubric > > This would make releasing a new version easier with the current support > from versioner. > Releasing a version for all three configurations at once would still > require some manual updating of versions, but that's a less frequent > use-case. > > Cheers, > Andrei > > > On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> exactly. >> what we need in the long term is a complete better integration process. >> I dream to have a git pharo project with submodules and pull requests. >> >> Slowly the tools are coming, but this will take time to implement. >> In the mean time, we need to do all the steps we can to allow us to >> achieve the modularisation goal. >> Even if they look not easy because we are still building it, or too used >> to previous ways of doing it. >> >> Esteban >> >> > On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > And do not forget that with better Pharo modularization it will start >> > to be a problem on more lower level. When eg. Morphic will be an >> > "exteranal" Pharo package. >> > >> > -- Pavel >> > >> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> >> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >> >> >> But this only works for releasing simple configurations that do not >> depend >> >> on other configurations. >> >> This would work for rubric, for example, but not for other >> configurations we >> >> have in gtools. >> >> >> >> >> >> then you have two options: >> >> >> >> 1) you rewrite your configurations to not need nested configurations. >> This >> >> is not recommendable in huge projects like Seaside, but things like >> GTools >> >> are easily (I did a quick check and your 3 configurations have in >> total 7 >> >> packagesâ¦ would not be a problem to have them without nesting projects >> and >> >> just using the packages). In fact, this is how Dale recommends using >> >> configurations (if I understood him right). >> >> 2) we enhance the tools to also allow the commit of nested packages. >> >> >> >> I think both approaches needs to be done: you donât need unnecessary >> >> complexity in your configurations and we need to add some nesting >> support to >> >> commit new version. >> >> >> >> What is not admisible, IMO, is to do something that is wrong just >> because it >> >> looks easier in the short term (and I say âin short termâ because what >> looks >> >> easier now will generate a lot of problems in the future). >> >> >> >> cheers, >> >> Esteban >> > >> >> >> > >

April 22, 2015