December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Could someone resuscitate the Google Groups mirror?

by Geert Claes

Probable the best way forward would be to contact the Pharo Google Groups admin and take over the admin duties -- View this message in context: http://forum.world.st/Could-someone-resuscitate-the-Google-Groups-mirror-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 16 December 2012 01:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. But it's a subset of the integers, not the reals! frank > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

[Pharo-project] Could someone resuscitate the Google Groups mirror?

by adrians

Could I ask that whomever set up the Google Groups mirror of this list get it back to working order? That mirror was kicked of this list last February for excessive bounces and at this point is dead. For one, this neglect doesn't look good for people happening onto Pharo from Google Groups. Second, I actually like to read my subscribed lists from as few different places as possible and while I like the Nabble front end, I have the vast majority of the many lists I follow on Google Groups and it would be nice to have this one under that umbrella, too. Fourth, having as many places from which people can interact with the Pharo community is a good thing, more exposure should be welcomed. If whomever set up the current group ( https://groups.google.com/forum/?pli=1#!forum/pharo <https://groups.google.com/forum/?pli=1#!forum/pharo> ) doesn't want to bother, could you at least kill it so I could set up a mirror myself? If on the other hand there is someone on the Pharo admin side who looks after this (but just forgot to do the maintenance here) could you please reset things so that messages are flowing again? While you're at it, could I ask that a Google Group be set up to mirror pharo-users as well? As I said, I could set up another mirror of this list myself, but it doesn't make sense to have two same name groups there. Much appreciated, Adrian -- View this message in context: http://forum.world.st/Could-someone-resuscitate-the-Google-Groups-mirror-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 16, 2012

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