- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versioner

by Christophe Demarey

Hi Stephan, Le 30 juin 2014 Ã 20:50, Stephan Eggermont a Ã©crit : > Kilon wrote: >> I disagreed with this Stephan >> >> "That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my >fears are unfounded." >> >> this what I was replying to. > > Ok. The concrete problem we ran into with the current version of Versioner is that it > wants to resolve dependencies to exact versions. For configurations depending > on Seaside, Magritte or Grease, this is normally unwanted. They should depend on > the symbolic release versions. With the high number of changes in Pharo, exact > versions have a short lifetime. I don't think it is the problem because the solving to exact versions is an option (You have a check box). The real problem is the support of platform-specific sections. > Dale wrote: >> In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) >> it is much easier to construct custom "tools" to support variations in workflow >> ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... > > In order to work together effectively in open source projects it is important that > contributors know what workflow is used in a project. That is easier when the > number of different workflows is limited. Because projects depend on other projects > the number of combinations of workflow is very large. Scriptable tools can easily > support these resulting combinations. Building a GUI tool that is both very flexible > and very easy to use seems to be less easy. Yes but some part are reusable. For example, Versionner uses MetacelloToolBox that was not thinked to support the current Versionner workflow. Versionner has some classes (model, commands) aside the GUI that can be reused for other workflows. Christophe.

July 1, 2014

Re: [Pharo-dev] Versioner

by stepharo

> Your response shows that I have not made my point well. I wanted to > point out that we need different workflows because of the different > demands. A workflow is more than only a tool, but starts with people > building something and ends with people using something. And you point > out that versioner has one workflow implemented, and therefor will not > be applicable to all projects. > > A. For pharo core all projects are included in pharo. The number of > external influences (VM, plugins) is very limited. It works here to > have no configuration at all, since there is only 1 release-branch: > the current one. And since the file server creates a version of each > build, we can always go back to a specific build. Quality is very > important to pharo as a lot of users depend on a good working pharo. But it should not be like that! Pharo should be modular too. And we need to have configurations. Why we cannot have better tools based on Roassal because we do not want to have a monolithic solution. So we should have a modular image and tools and process to get there. > B. For the âcross-platformâ projects this workflow is not sufficient, > because there are much more external influences. So here we use the > configurations to manage the releases. And the complexity of the > configuration of Seaside shows this is a very complex thing to do. > This complexity is not from Metacello. Metacello allows us to do a > decent job here for the supported platforms. For the unsupported > platforms there is some additional manual work involved, with all > risks to this. The complexity here stems from the Software > Configuration challenges Seaside faces. A simple inbox wonât do the > job for us. Quality here is also very important as a lot of users > depend on a good working Seaside. Also there are more demands on > reproducibility, as there are quite some systems depending on Seaside > that should function 24/7. > > C. For the âmooseâ projects, we have a few advantages above the > cross-platform projects, and a few disadvantages: > + Moose only needs to work for pharo. So we can cut out a lot of > platform specific junk. Some projects are suited for multiple > platforms, but not for the amount of platform Seaside should work on. > + There are far less projects depending on Moose. Most of them are > integrated, so tests will automatically be fired. And the projects > that do depend on Moose usually do not have run 24/7. > - Moose depends on more projects then Seaside. To create an exact > version is therefor much harder. > - A large part of the Moose bugs comes from the change rate of the > projects Moose depends on. Pharo has a very drastic strategy to > improve its architecture. This causes quite some maintenance work. > So that there is no review is not the point. The point is that because > of these different demands we need to accept a lower quality standard > for moose. This lower quality standard is maybe undesirable, but is > not easily improved. Having no review is a consequence of this, not > the cause. If we want to improve this quality standard, better SCM > tools will not suffice. On the other hand, this lower quality standard > has so far worked for Moose, as there are less people who depend on Moose. > > Regards, > Diego

July 1, 2014

Re: [Pharo-dev] Versioner

by stepharo

>> That is exactly my point. But Stef currently tries to enforce this >> workflow of working to Moose. And since this workflow will not work >> well for Moose (because of the demands on the process), I object to this. > > I don't think Stef wants to impose the workflow. Stef wants to improve > code modularity in Moose and avoid broken / bad configs. > Moose is a big project and one solution to ease the maintenance is to > use a tool (Versionner for example). > Now it is clear that Versionner does not have all features to support > the Moose process and I will take some time to see how to implement a > smart deep release. > With that, it should be enough to support Moose workflow. We want to have a working workflow :) And the point is to make one becoming true. After we can discuss. Stef

July 1, 2014

Re: [Pharo-dev] Project XMLParser green

by Tudor Girba

Thanks. Just please detail what happened and why Versionner should not be used. Only like that we can learn and coordinate. Doru On Tue, Jul 1, 2014 at 11:39 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Bad configuration, fixed. Do not use current version of versioner for this > configuration > > Stephan > -- www.tudorgirba.com "Every thing has its own flow"

July 1, 2014

Re: [Pharo-dev] numeric pad

by Hilaire Fernandes

Normally this problem was solved for linux. Mine about 10 of june has a working keypad. Try to fetch one from this period in the different builds, if possible. Hilaire Le 01/07/2014 02:01, Pablo R. Digonzelli a Ã©crit : > Hi all , i need numeric pad working for a linux application. > I probe last pharo and last squeak vm and images and does not work . > I need to solve it in order to continue developing a business app . > Can anybody help me? > > > **** > ------------------------------------------------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

July 1, 2014

Project XMLParser green

by Stephan Eggermont

Bad configuration, fixed. Do not use current version of versioner for this configuration Stephan

July 1, 2014

XMLParser

by Diego Lont

Guillaume, Have you tested the new version of XMLParser on an old pharo 1.x version? If not, will you please revert your change in this configuration, as this will break it. Regards, Diego

July 1, 2014

Re: [Pharo-dev] functions keys

by Nicolai Hess

Function keys do generate events, but no keystroke event, just keydown and keyup. you can implement handleKeyDown: or handleKeyUp: on a Morph, and it will be called on Functionkeys as well. 2014-07-01 1:55 GMT+02:00 Pablo R. Digonzelli <pdigonzelli(a)gmail.com>: > Guille , functions key does not generate event at all. > I think it is a problem for some applications. > > > > > ------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > ------------------------------ > *De: *"Guillermo Polito" <guillermopolito(a)gmail.com> > *Para: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *CC: *"Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > *Enviados: *Lunes, 30 de Junio 2014 19:26:23 > *Asunto: *Re: [Pharo-dev] functions keys > > > To handle function keys you should handle the keyup or keydown event. > Then, the KeyboardEvent has a #key method to get the pressed key. > > Take a look at the Key class side methods to access well known keys. > > Guille > > > On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli < > pdigonzelli(a)gmail.com> wrote: > >> >> After exploring the image I believe functions keys (F1,F2, etc ) are not >> handling by KeyboardEvent class. >> I think it is very common use that function keys in business >> applications. Someone know if i am true about this topic? . >> Or maybe someone handling functions keys in an application? >> >> TIA >> >> ------------------------------ >> *Ing. Pablo Digonzelli* >> Software Solutions >> IP-Solutiones SRL >> Metrotec SRL >> 25 de Mayo 521 >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> >> >> > >

July 1, 2014

Re: [Pharo-dev] [ANN]: Little NeoJSON Helper

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I just don't know, what do you think about it in retrospect ? Thanks for taking a look! I don't know either :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763p4765873.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 1, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Igor Stasenko

On 30 June 2014 21:36, Nicolai Hess <nicolaihess(a)web.de> wrote: > The real question was: > Why can't we draw a text with StrikeFont and with Athens. > > Igor, can't we use AthensCairoText (cairo toy text api) for non-truetype > fonts? > > Because strike fonts are stored in special format which you cannot render directly by cairo library. Because strike fonts are not scalable. Because it will be horribly slow. Choose one. > > > > 2014-06-21 1:20 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > > Gi Igor, >> >> For DrGeo it is not a workable option to have different fonts in Morphic >> widget and Athens canvas (I explained earlier why). >> However I found the scaling trick of draw text to work reasonably well. >> Not full perfect as from time to time I can see some artifact. >> >> Thanks >> >> Hilaire >> >> >> >> >> Le 20/06/2014 15:32, Igor Stasenko a Ã©crit : >> > Sure, you can do: make sure you don't render text with same font in >> > Morphic UI and Athens, so they don't interfere with each other. >> > There's no easy way to get rid of interference, because it would require >> > changing Freetype package and its plugin in order to establish a single >> > font management point and funnel all requests to freetype library >> > through it. >> > >> >> -- >> Dr. Geo http://drgeo.eu >> iStoa - https://launchpad.net/istoa >> >> >> > -- Best regards, Igor Stasenko.

July 1, 2014