- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About (backwards) Compatibility

by Esteban A. Maringolo

I agree with what most people have said, from "both" sides. Most of the Smalltalkers I know that are making a living out of it are small teams, if not single developer companies (letting aside the fact my company have more than a dozen of smalltalkers). The transition path should be done as painless as possible for the current users of Pharo, given the restricted manpower such teams have. On the other hand going from 1.4 to 2.0 is a major release, and it has its tradeoffs, so to have the improvements you have to sacrifice some things, the Pharo team COULD make everything backward compatible, but it has a limited manpower too. There is certainly a PR issue here, as an outsider to the Pharo community (but watching it close since some time) I've been seeing an increment of "harsh" responses to those requesting features or "wishes" for the project (without considering the fact that some might have good or bad intentions). My POV on this is that Pharo, by means of its "board/committee/team", have a strong decision on where to take the future of it, it will accept improvements and contributions, but in the end they're going to be the curators of the final product, like a vendor would do it. And I think that's a good thing, projects need a "benevolent dictator". It's a matter of time to see the results of the path taken. "If Henry Ford had asked his customers, they would have told him they want a faster horse...'' I certainly do not want a faster horse. Regards, -- Esteban M. -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659411.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Sean P. DeNigris

Chris Muller-3 wrote > I think we agree about what good design is, we just differ about which > path to take there, the more-compatible or the more-beautiful path. That sums it up I think :) -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Chris Muller

FileDirectory was updated in 2009, but since Pharo had already forked off Squeak prior to that you didn't know that FileDirectory was already a lot like FileSystem is today before anyone knew FileSystem even existed. Today these examples are almost identical. > Example #1: > file := FileDirectory directoryEntryFor: '/path/to/file'. > FileDirectory extensionFor: file name. > > vs. > > file2 := '/path/to/file' asFileReference. > file2 extension. file := FileDirectory directoryEntryFor: '/path/to/file'. file extension > #2: > (FileDirectory on: 'path') entryAt: 'nohup.out'. > vs. > 'path' asFileReference / 'filename' (FileDirectory entryFor: 'path') / 'filename'. I agree we should add String>>#asDirectoryEntry to avoid the keyword message and parenthesis, so both examples would be just as nice as FileSystem: 'path' asDirectoryEntry / 'filename'. I think we agree about what good design is, we just differ about which path to take there, the more-compatible or the more-beautiful path.

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Igor Stasenko

On 15 December 2012 23:45, Chris Muller <asqueaker(a)gmail.com> wrote: >> and i always hitting the wall with my head again and again.. because >> there's no such protocol >> and instead (after opening browser and looking at class, i figuring >> that i should use #first/#last, but it is completely unintuitive to >> me).. > > Me too, when I was using what I knew would only ever need to be, > simply, an Interval. > > Later the complexity increased and it would be either a Interval or > Array of numbers. It was a transparent / painless improvement. After > gaining that appreciation, now I think of Intervals as just "efficient > Arrays" and think naturally to use #first / #last. > Well, my math background prevents me from thinking this way. Since in math, intervals are defined on sets of numbers. (like Real set).. you cannot treat it as array , simply because there is an infinite number of values inside any non-empty interval, and you cannot enumerate them. -- Best regards, Igor Stasenko.

Dec. 16, 2012

[Pharo-project] new Cog VMs available

by Eliot Miranda

Hi All, new Cog VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r2636/. The main change here is to do with corrected headroom and safer signal handling which should hopefully improve stability on linux. Cog VM binaries as per VMMaker.oscog-eem.234/r2636/r2638. Use the -z now link flag on the linux builds. This causes the dynamic linker to resolve unresolved symbols on load instead of lazily. This affects reliability in signal handlers, because if the dynamic linker can run at any time it can therefore run in a signal handler and cause a deep call chain which could corrupt a stack page in the JIT. So this aplies three fixes to this issue: a) correct the stack headroom determination b) use sigaltstack for signal handlers in the UnixOSProcessPlugin c) link using -z now on linux. Use SA_ONSTACK/sigaltstack for signal handlers installed by the UnixOSProcessPlugin to avoid running signal handlers on the JIT's stack. (r2638: Check for needing sigaltstack properly in setSignalNumber:handler:). ==== VMMaker.oscog-eem.233/r2632 Rename misnamed internalIsMutable: and internalIsImmutable: to isOopMutable: and isOopImmutable:. Affects sqVirtualMachine.c, but only part of api used in Newspeak VMs. Merge LargeInteger primitive fixes from VMMaker-dtl.286 and tests from VMMaker-dtl.289. UnixOSProcessPlugin: Merge with VMConstruction-Plugins-OSProcessPlugin-dtl.35. In particular restore missing code to forwardSignal:toSemaphoreAt: Get plugin to use SA_ONSTACK/sigaltstack for signal handlers if loaded in the JIT. ==== VMMaker.oscog-eem.230/r2631 Fix stackPage headroom calculation in CoInterpreter. Was getting things backward. This increases the stack page headroom by 62% from 1564 bytes to 2532 bytes. Shootout benchmarks unchanged, so reduction in frames per page is not an issue for typical code. This should result in fewer crashes on linux where the dynamic linker, if it kicked in during a signal handler, could cause a deep call chain at interrupt time and trample the start of the adjoining stack page. Merge LargeInteger primitive fixes from VMMaker-dtl.286. Change generation of plugin code so that internal plugins call VM routines directly and external plugins call through their own local copies of the function pointers in InterpreterProxy. External plugins copy the InterpreterProxy functions to their local copies in setInterpreter:. Change implementations of stObject:at:put: to return their value, to match the declaration in InterpreterProxy. Streamline ObjectMemory>>instantiateClass:indexableSize: (hdrSize and header3 change together). Optimize the debug VM by making startOfMemory a macro that answers heapBase instead of a method. Improve stack page printing, and make stack trace printing more robust (findClass/SelectorOfMethod:forReceiver:). Make temporary:in:put: et al answer their values. For stObject:at:put:. Make jumpTable size err message more explanatory. Rename misnamed internameIsMutable: and internalIsImmutable: to isOopMutable: and isOopImmutable:. Affects sqVirtualMachine.c, but only part of api used in Newspeak VMs.-- best, Eliot

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Sean P. DeNigris

H. Hirzel wrote > As Chris points out, the difference is minimal. > > Sean, it looks like you need better examples to show how you perceive > the benefits of the FileSystem design While you ignored the point of my followup post, which is that beauty and simplicity lead to more than the sum of a few keywords, here are a few basic examples... Example #1: file := FileDirectory directoryEntryFor: '/path/to/file'. FileDirectory extensionFor: file name. vs. file2 := '/path/to/file' asFileReference. file2 extension. #2: (FileDirectory on: 'path') entryAt: 'nohup.out'. vs. 'path' asFileReference / 'filename' "Most operations routed through one massive FD class" vs. "immediate access to the domain object you want"; not to mention the appreciated absence of parens. No difference?? -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659396.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 15, 2012

Re: [Pharo-project] Interval protocol

by Chris Muller

> and i always hitting the wall with my head again and again.. because > there's no such protocol > and instead (after opening browser and looking at class, i figuring > that i should use #first/#last, but it is completely unintuitive to > me).. Me too, when I was using what I knew would only ever need to be, simply, an Interval. Later the complexity increased and it would be either a Interval or Array of numbers. It was a transparent / painless improvement. After gaining that appreciation, now I think of Intervals as just "efficient Arrays" and think naturally to use #first / #last.

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Igor Stasenko

On 15 December 2012 13:39, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > > > Dne 15. 12. 2012 12:46, piÅ¡e Igor Stasenko: > >> Hold on.. Since when Pharo project became professional product? >> How much money you and others paying for using it? >> Yes, we position it as a product FOR professionals, >> but does it automatically makes a professional one? >> I don't think so. >> So, why you think that it is correct to put such requirements/expectations it? > > Let me explain what I meant by 'professional product'. Product for > professionals implies the characteristics of professional product. Even > if it is an open source one and partially paid by donations. One of the > main characteristic is a clear path of upgrading to a new version. > Another is a proper 'Customer Relationship Management'. > > BTW, ask Gemstone guys for help here, they are very good in migration > help to the new version and evolution to the new features. Not to > mention their amazing attitude to the customers. > > To conclude, a bit better PR would make wonders here. Sometimes we need > just to listen to our users even that we don't agree with them. Again > one of the characteristics of professional product behavior, like it or > not. > Janko, let me explain what means "legacy code": - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand Why do you think, a Debugger source mapping are still not fixed over couple years in pharo? Just for curiosity, go and look at the source code involved there.. and try to figure out where the bug is and what needs to be fixed. Or try to understand how events are handled by Morphic.. And since you started talking about PR, think about what PR such code makes each time developers (and especially newcomers) facing it... P.S. If you like FileDirectory so much, print it and put it in a glass case. It deserves some resting place after years of servitude :) -- Best regards, Igor Stasenko.

Dec. 15, 2012

Re: [Pharo-project] Interval protocol

by Pavel Krivanek

You are not, I need to always recheck the Interval class to see what messages to use. -- Pavel On Sat, Dec 15, 2012 at 5:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > hi, > > i am alone with this problem (or just mentally ill?), why every time i > use #start and #end protocol for Interval, e.g.: > > start := (1 to: 100) start. > end := (1 to: 100) end. > > why i expecting that something called 'interval' should answer its > start and end (or begin & end, if you like)? > > and i always hitting the wall with my head again and again.. because > there's no such protocol > and instead (after opening browser and looking at class, i figuring > that i should use #first/#last, but it is completely unintuitive to > me).. > > So, i am alone with this? Or maybe intervals deserving to have start and > end? > > > > -- > Best regards, > Igor Stasenko. > >

Dec. 15, 2012

[Pharo-project] Interval protocol

by Igor Stasenko

hi, i am alone with this problem (or just mentally ill?), why every time i use #start and #end protocol for Interval, e.g.: start := (1 to: 100) start. end := (1 to: 100) end. why i expecting that something called 'interval' should answer its start and end (or begin & end, if you like)? and i always hitting the wall with my head again and again.. because there's no such protocol and instead (after opening browser and looking at class, i figuring that i should use #first/#last, but it is completely unintuitive to me).. So, i am alone with this? Or maybe intervals deserving to have start and end? -- Best regards, Igor Stasenko.

Dec. 15, 2012