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

[Pharo-project] Monticello trickery: pointers needed
by Frank Shearar Jan. 4, 2012

Jan. 4, 2012

Hi, The background to the question is that I'm trying to repackage LanguageBoxes so that both the Squeak and Pharo community can use its features (or just parts of it). Cutie-Helvetia defines a class, CURaisedToExample. Among others, it defines two methods: CURaisedToExample class >> #raise:to and CURaisedToExample >> testSplice. The latter makes use of QQCompiler's splice operation (just like Common Lisp's) - @foo will replace 'foo' with whatever 'foo' evaluates to, so compiling 'a := @(3 + 4)' means the same thing as 'a := 7'. Now testSplice says self assert: `@(self raise: 2 to: -3) = (1/8). which means that, _at_compile_time_, testSplice will invoke #raise:to: (the self refers to the class-side method)... and at this point in time #raise:to: has been compiled, but not installed. Compiling #testSplice fails with a MessageNotUnderstood, and package loading aborts. My question is this: how can I work around this? Can I move the installation of #raise:to: to a preload step? Some hacks that spring to mind, and don't seem very pleasant, are: * introduce a new superclass defining the method, put that in a seperate package, and load that package before Cutie-Helvetia * move the definition of CURaisedToExample and #raise:to: to a separate package, and make all the tests extensions to that package. frank

1 1

[Pharo-project] TWM Bug - different world menu
by Sean P. DeNigris Jan. 4, 2012

Jan. 4, 2012

When I access the world menu through the TWM bar, some of the items I have registered do not show up. Maybe items added after TWM was loaded do not show up. Anyone else notice this? Sean -- View this message in context: http://forum.world.st/TWM-Bug-different-world-menu-tp4244649p4244649.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 2

[Pharo-project] Bug Report: 6 of 6: Settings
by S Krish Jan. 4, 2012

Jan. 4, 2012

6. Settings: On Ubuntu Linux and on Windows: Go to the Network node and change the values for HTTP Proxy/ Proxy Authentication and quit and comeback.. Does not retain the settings.. ******************** Also .. I add it here.. though disconnected from the above.. but for Settings issue.. Sound Package: Well this one set of hack throughs to get it working on Linux.. Straight after loading the packages: Settings tab does not show up the 3+ lines of setting on loading the SoundSetting package.. Fails on Phenome** method not being initialized.. Go hack and comment some places in the code it starts to work beautifully thereafter.. will try and reap/ move hacks to more usable code and submit..

5 8

[Pharo-project] Call for papers - Science of Computer Programming: Special Issue on "Advances in Dynamic Languages"
by jannik.laval Jan. 3, 2012

Jan. 3, 2012

================================================ Special issue on "Advances in Dynamic Languages" ================================================ Special issue of Elsevier's Science of Computer Programming (SCICO) Context ------- Over recent years we have seen an increased interest in dynamic programming languages such as Smalltalk, Lisp, Scheme, PHP, JavaScript, Self, Python, Ruby, and so on. These languages have taken a prominent role in teaching, web development, scripting, rapid prototyping, tool building, language engineering, and many other domains. For this special issue we invite high-quality papers that focus on novel research related to dynamic programming languages and applications of these languages. We are interested in research that uses dynamic languages in the context of, but not restricted to: - Aspects, aspect Languages and applications. - Ambient intelligence, ubiquitous / pervasive computing and embedded systems. - Compilation technology, optimization, virtual machines. - Language engineering, extensions. - Model-driven engineering / development. - Meta-modeling, reflection and meta-programming. - Programming in the large; design, architectures and components. - Programming environments, browsers, user interfaces, UI frameworks. - Source-code analysis and manipulation (static analysis,refactoring, type inference, metrics). - Testing, eXtreme Programming / practices. - Web services, internet applications, event-driven programming. - Experience reports. The special issue is associated with the Smalltalks 2011 conference. The Smalltalks series of conferences (www.fast.org.ar) is a lively forum on Smalltalk-based software technologies that brings together more than 200 people from both academia and industry for a period of three days. Submission Guidelines --------------------- Papers should be written in English, in PDF-format and should not exceed 25 pages (including references and figures), using the Elsevier journal format. The LaTeX template for this format can be found at http://www.elsevier.com/wps/find/authorsview.authors/latex Papers must be submitted through the EES submission system located at http://ees.elsevier.com/scico/default.asp When reaching the "Article type" step in the submission process, it is important to select "Special issue: Advances in Dynamic Languages". Each paper will be reviewed by at least 3 experts within the domain. The accepted papers will be published in a special edition of Elsevier's Science of Computer Programming. Papers submitted must not have been previously published (at least 30% new material) and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Jannik Laval (jlaval(a)labri.fr) and Andy Kellens (akellens(a)vub.ac.be) Important dates (tentitavely) ----------------------------- - Submission round 1: March 16, 2012 - Feedback round 1: May 17, 2012 - Submission round 2: June 29, 2012 - Feedback round 2 (final notification): August 17, 2012 - Camera ready version: September 14, 2012 Guest editors ------------- Andy Kellens (Vrije Universiteit Brussel, Belgium) Jannik Laval (LaBRI Bordeaux, France)

1 0

[Pharo-project] Category to be ignored by Monticello?
by Dave Mason Jan. 3, 2012

Jan. 3, 2012

I have some code that generates code on the fly in user classes. I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved. I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories. Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello" Thanks ../Dave

2 1

[Pharo-project] [ VM ]Smalltalk getSystemAttribute:
by StÃ©phane Ducasse Jan. 3, 2012

Jan. 3, 2012

we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message: > VM.r2518/. > > CogVM binaries as per VMMaker.oscog-eem.139/r2518. > > Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: > Smalltalk getSystemAttribute: > -1 => executable name > -2 .. -n => VM arguments *including* image (if explicitly supplied). > Replace win32 command line parsing with unixesque code using CommandLineToArgvW. > > linux launch script: > Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage > version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to > LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. > -- > best, > Eliot >

10 18

[Pharo-project] About announcements
by Igor Stasenko Jan. 3, 2012

Jan. 3, 2012

On 2 January 2012 10:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>> >>> The size is the least problem. >>> >>> More annoying is that the code quickly gets out of sync and >>> non-changes are added to the history. Both of these problems are >>> already visible today. >>> >>> Additionally, over time people will change/add/remove features that >>> get integrated without proper review. I just had a look at the >>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>> tiny framework could degrade to a bloated, untested and dead slow pile >>> of mud in just a few years :-( >> >> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. > > Nice argument for your students reading this thread: > http://memegenerator.net/instance/12779750. > >> But, what do you mean by slow? How did you benchmark it? > > No, but if you look at the code you will see many extra steps: > > 1. It tests if a registry is there: Why would that be necessary in an > object-oriented implementation? > this should be cleaned up. i think it is a leftover from migration code from old Announcer class (pre 1.3) to a new one. We did things incrementally, and had code to migrate all instances from old format to a new one, without losing subscription and without stopping working. > 2. It tests if the registry is empty: Why would that be necessary in > an object-oriented implementation? > not necessary. looks like a optimization. > 3. It enters a critical section of a monitor: This is rarely useful > and the slowest kind of concurrency control available in Pharo (a > Mutex would be enough for what it is used for, and instantiate > multiple semaphores and queues), and btw the lazy initialization of > the monitor is the prime example of a race condition. > agreed here. I would even leave a semaphore. I think it is overlooked by Henrik. It also don't needs a lazy initialization in #protected: , since in #initialize it can just create a ready for use fresh synchronization object. > 4. It creates a copy of the collection of all the subscriptions: This > is rarely useful and wouldn't be necessary if an immutable data > structure was used. > propose better solution how to deal with situation when during handling an announcement, your handler unsubscribing from announcer. > 5. It iterates over all announcements, it doesn't even try to group > announcements of the same kind. > it is pointless to group them, and makes no real difference. Because announcer doesn't knows what kinds of announcements will be announcement, and it knows only about subscriptions. Suppose i have a subscription to Announcement. And i announcing AnnouncementA (a subclass of it). Now it is still have to iterate over inheritance chain in order to determine if given subscription should receive it or not. Of course you can put all subscriptions to Announcement into one group, so you don't need to check it for every subscription: dict at: Announcement put: group. .... so you can do: group do: [:subscription | subscripton deliver: announcement ]. but that imposing that you have a fixed model for announcement relationship, while with #handles: i can simply make it so, that my announcement class are not inherits from its superclass and so, even if you subscribe to Announcement, you won't receive an announcements of my kind, because it simply doesn't walks an inheritance chain in its #handles: method. also, in the end i don't think it matters. Grouping is more optimal (potentially), but you won't see any difference unless you have hundreds of subscriptions, so i think it is not a big deal. Usually there are few subscriptions held by announcer. And so there is simply no need to bother and grouping them. I cannot imagine an announcer holding hundreds or thousands of subscriptions. Announcer allSubInstances collect: [:e | e numberOfSubscriptions ] an OrderedCollection(0 0 1 0) > 6. It wraps each announcement delivery into a curtailed block. It does > that even for those that are never actually announced. > yeah, this can be optimized > 7. It then tests each announcement if it matches, again it doesn't > even try to group the announcements of the same kind. Aside, the match > test was changed so that it doesn't allow instance-based announcements > anymore, breaking some of my code. > what is instance-based announcements? you can use any object as a subscription selector, just make sure it understands #handles: message. i.e. announcer on: myObject do: [ ... ] where myObject can be any object, not just Announcement (sub)class. > 8. It then wraps the actual notification into an exception handler. > Again, this is rarely useful and should probably rather be something > pluggable. > perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) But for things like SystemAnnouncer, this is not a question that exception handler must be present and delivery must be guaranteed. > 9. It then culls the announcement and announcer into the block. Not > sure why the announcer is useful, after all the block was registered > with the announcer at some point. > cull there is for passing optional arguments. > So all these 9 steps are not really necessary (or even wanted) in most > case. I doubt that any of them makes the code faster. I am glad that > the code works for you even if all of this new functionality is > untested. And good luck with the race condition :-) > >> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. > > Do you really believe that stripping away unwanted material works? No > other open source project in the whole world does it like that, > everybody builds distributions on top of a smaller core: Linux, GCC, > Gnome, FireFox, ... Even in the supermarket, you typically don't get a > vegetable hamper if you just want a some potatoes. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.

6 14

[Pharo-project] Bug reports: 1 of 6: Damaged Window/ rectangles on Screen
by S Krish Jan. 3, 2012

Jan. 3, 2012

1. Damaged Window rectangle painting all over.. as you drag the window over the World.. * This is just the repeatable test, but occurs very annoyingly with an image if we have debugged through some piece of Morphic UI code.. Infact this damaged rectangles/ lost refresh of World occurs very frequently with ordinary non forked UI stuff also. of other variants viz: SystemWindow etc.. * Transcript if used on / or STranscript.. the World repaint many a times starts popping up its TextMorph through other top windows.. while it sends the transcript text to it. [ | dialog builder | builder := UITheme exampleBuilder. dialog := builder newPluggableDialogWindow: 'BasicTestDamagedWindows'. dialog contentMorph: (dialog newRow: {dialog newColumn: {dialog newColumn: {dialog newTextEntryFor: (ValueHolder new contents: 'text') getText: #contents setText: #contents: help: 'hostName'}}}); model: self. World openModal: dialog ] fork.

2 1

[Pharo-project] TWM bug when deleting a snapshot
by Sean P. DeNigris Jan. 3, 2012

Jan. 3, 2012

Snapshots are cool! But try this: 1. create two snapshots 2. navigate to the last one 3. delete it Although it is shown removed from the list (i.e. "1/1"), you are not automatically navigated back to the first one. You stay on the deleted one, and when you navigate back to the first with the arrow, the deleted one reappears in the list (i.e. "1/2") Sean -- View this message in context: http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4243197.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 5

[Pharo-project] how to test drag and drop?
by Tudor Girba Jan. 3, 2012

Jan. 3, 2012

Hi (Sean), I would like to test some drag and drop functionality but I do not know how. The BDDExtensions already provides support for simulating clicking, but not drag and drop. Is there an easy way to add this? Cheers, Doru -- www.tudorgirba.com "Reasonable is what we are accustomed with."

1 0