- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versioner
by Stephan Eggermont July 2, 2014

July 2, 2014

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. 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. Stephan

3 2

New Cog VMs available...
by Eliot Miranda July 1, 2014

July 1, 2014

at http://www.mirandabanda.org/files/Cog/VM/VM.r3024/. I had *forgotten* to implement following forwarders on primitive failure in machine code primitives, hence Cog Spur was badly broken. It's now a little bit better, but I still need to implement this for named primitives. Real soon now I hope... CogVM source as per VMMaker.oscog-eem.791/r3024 Implement following forwarders on primitive failure in machine code interpreter primitives (still have to implement this in sideways calls of named primitives). Allow the JIT to not compile primitiveDoNamedPrimitiveWithArgs to avoid any potential complications. Rewrite all the semaphore installing primitives to fail if the semaphore arg is neither a semaphore or nil instead of assuming if its not a semaphore it must be nil, so as to fail and retry when semaphores are forwarded (as they are when Semaphore is redefined). Implement isSemaphoreOop:/Obj: in the object memories to abstract away the code. Base Spur's on the class index of splObj: ClassSemaphore, avoiding the table lookup to derive the class. Make checkForEventsMayContextSwitch: treat all its semaphores consistently. Have spur's fetchClassOfNonImm: answer nilObj for forwarders to avoid assert fails. On Spur add read barriers to primitiveSuspend and synchronousSignal:'s myList access, because the process list manipulation routines do no checking. Add assert checks for forwarders in the process list manipulation routines. Fix slip in StackInterpreter>>actuallyFollowNecessaryForwardingInMethod:literalCount: that corrupts the methodClassAssociation. Abstract out the call machinery from compileTrampolineFor:numArgs:arg:arg:arg:- arg:saveRegs:pushLinkReg:resultReg: so it can be used by maybeCompileRetry:onPrimitiveFail: in implementing following forwarders on primitive failure in machine code, and the Open PIC miss call. Have bytecodePCFor:cogMethod:startBcpc: map any pc before the stackCheckOffset to the initialPC, which applies to primitives in progress. Fix assert fails in updateStateOfSpouseContextForFrame:WithSP: and elsewhere with forwarders. LargeIntegers Plugin: Fix a latent signed shift bug in cDigitSub:len:with:len:into: caused by VMMaker.oscog-eem.785's eliminating the divide-via-shift optimization. These changes allow Cog Spur to redefine Process and/or Semaphore and not hang. -- best, Eliot

1 0

functions keys
by Pablo R. Digonzelli July 1, 2014

July 1, 2014

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

4 10

numeric pad
by Pablo R. Digonzelli July 1, 2014

July 1, 2014

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

4 7

[ANN] Amber 0.12.6 released!
by Nicolas Petton July 1, 2014

July 1, 2014

Hi! After two months of development we are happy to announce the release of Amber 0.12.6 (skipping 0.12.5 for technical reasons). The team has once again been busy improving Amber to make it rock more than ever! With 260 commits done by 8 contributors, this release brings several important improvements as well as the usual bug fixes. Highlights: - Helios now has a test runner - The `amber-cli` npm package installs the CLI tooling. `amber` is not to be installed globally any more. Instead, install `amber-cli` with `npm install -g amber-cli`. - New `amber-init` command: After installing the cli tooling, `amber init` initializes a new project. - `amber` and `amberc` cli tools can now be found in the `external` directory and in dedicated npm packages. - Amber now parses `$c` character literals. - Bootstrap 3 can be used in Amber projects (no more nameclash with Helios' bootstrap 2 using bootstrap2.3.2 name). - Wider range of jQuery versions allowed. API changes: + String >> + value: + ProtocolAnnouncement >> + package + Behavior >> + isTestClass + Package >> + isTestPackage + amber/{devel,deploy,lang} exports + nil + amber/helpers exports + nil We would like to thank the contributors who made this release possible, and especially Ryan Simmons for his work on the Helios Test Runner. /The Amber crew.

1 0

Versioner
by Diego Lont July 1, 2014

July 1, 2014

I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started. I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. 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. Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind. The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know. 1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows: A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards. B. For the âcross-platformâ projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a âreleasedâ version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues. C. For the âmooseâ projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes. I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale): When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported. 2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this? 3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too? And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ... 4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem. Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways. 5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures. Regards, Diego

4 6

XMLParser
by Diego Lont July 1, 2014

July 1, 2014

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

1 0

numeric pad
by Pablo R. Digonzelli June 30, 2014

June 30, 2014

i actualized the vm for linux , but numeric pad of keyboard does not work. The keys are captured (exists KeboardEvent ) but the keys are not displaying in workspace for example. 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

1 0

Re: [Pharo-dev] Versioner
by Stephan Eggermont June 30, 2014

June 30, 2014

Kilon wrote: >I just don't see it the way you do. That's fine, you work in a different context than we do. What do you disagree on? You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation. >For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations. >What stops anyone from implementing his own configuration tool ? Common sense, I hope... Stephan

4 5

Amber frontend with Pharo backend
by Sebastian Sastre June 30, 2014

June 30, 2014

Hi guys, cross-posting to Amber groupâ¦ Iâve recently published the code of http://tasks.flowingconcept.com Here: http://github.com/sebastianconcept/tasks Have fun sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

1 0