- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor
by Fernando Olivero Feb. 1, 2012

Feb. 1, 2012

Nothing prevents from registering an instance of UserInterruptHandler , outside the Sensor code. But i've noticed that this registering was done in #installEventSensorFramework:, and no reference to the interrupt handler was kept by the Sensor. So made me think that Sensor should keep a reference to it. The question is wether we need a special case for the UserInterruptHandler, i think we should not. By special case i mean, an extra single purpose "Sensor". It could be done more transparently by relying on a single Sensor. Evidence of it is that UserInterruptHandler can be customized for any keystroke, yet the settings are called CmdDotEnabled. Using the new Event-Model, user interrupts can be customized by the client processing the system events, no need to have a special user interrupt handler class. The client would process a normal SystemKeyboardInputEvent, and do whatever it wants in case the keystroke was the current user-interrupt keystroke. For example, in Gaucho : GKeyboard>>keystroke: aGKeystroke â¦. aGKeystroke isUserInterrupt ifTrue:[ userInterface processUserInterrupt ]. ... In Morphic, the HandMorph would have this responsibility. Or we can push this bypassing of the keystroke handling to the SystemEventsAnnouncer. Does it make sense? Fernando On Wed, Feb 1, 2012 at 4:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > err... you seems like crossing multiple layers by doing that. > > Because before you were able to have interrupt handler without having a sensor. > Now you cannot have interrupt handler without having sensor installed. > > On 1 February 2012 14:14, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Please integrate/review this one. >> >> >> In the context of replacing the current event handling mechanism, for >> the new Event-Model using announcements, i found out that the >> UserInterruptHandler is somehow treated as a global. >> >> See >> >> Â InputEventSensor>>installEventSensorFramework: fetcherClass. >> Â Â â¦. >> Â Â "Register the interrupt handler" >> Â Â UserInterruptHandler new registerIn: InputEventFetcher default. >> Â Â â¦â¦. >> >> What if you want to replace the user interrupt handler for another? It >> cant be done transparently. >> >> I've added the userInterruptHandler as an ivar of the current Sensor, >> so when it registers and unregisters, it takes care of registering and >> unregistering its user interrupt handler. >> >> So you can plug different user interrupt handlers to the current sensor. >> >> >> >> >> Fernando >> > > > > -- > Best regards, > Igor Stasenko.

1 0

[Pharo-project] Collection new
by Andrew P. Black Feb. 1, 2012

Feb. 1, 2012

Teaching a class of novices, it's not surprising that someone tried "Collection new". What was surprising is that this got the VM is a loop of some kind, with emergency stack dumps and so on. Here is my reply: > On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote: > >> ...it's pretty innocent: >> Collection new > > > OK. I looked at this. The problem comes when trying to print the collection. Somehow the VM gets confused when trying to do do: ... I'm not quite clear why. > > The quick fix is to change the Collection>>new method to > > self error: 'Collection is an abstract class, and cannot be instantiated' > > However this will break Heap>>new: , which sends super new. It ought to send self basicNew instead. > > These two changes seem to avoid the problem, but I'm waiting to see ... > > Andrew But I don't understand the root cause. Printing eventually sends do:, which is self subclassResponsibility. Why don't we get a clean failure? Andrew

6 8

[Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor
by Fernando Olivero Feb. 1, 2012

Feb. 1, 2012

Please integrate/review this one. In the context of replacing the current event handling mechanism, for the new Event-Model using announcements, i found out that the UserInterruptHandler is somehow treated as a global. See InputEventSensor>>installEventSensorFramework: fetcherClass. â¦. "Register the interrupt handler" UserInterruptHandler new registerIn: InputEventFetcher default. â¦â¦. What if you want to replace the user interrupt handler for another? It cant be done transparently. I've added the userInterruptHandler as an ivar of the current Sensor, so when it registers and unregisters, it takes care of registering and unregistering its user interrupt handler. So you can plug different user interrupt handlers to the current sensor. Fernando

2 1

[Pharo-project] [update 1.4] #14301
by Marcus Denker Feb. 1, 2012

Feb. 1, 2012

14301 ----- Issue 5226: Add 2 methods in Browser API to allow to easily register groups http://code.google.com/p/pharo/issues/detail?id=5226 Issue 5225: Remove PseudoContext http://code.google.com/p/pharo/issues/detail?id=5225 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] a problem with a MorphTreeMorph with headers
by Esteban Lorenzano Feb. 1, 2012

Feb. 1, 2012

Hi, I have a problem for an application I have: I'm displaying a MorphTreeMorph who has a header and some columns, problem is when morph has a horizontal scrollbar and I need to go down, last element on list is covered by horizontal scroll bar and customer can't see his data. I need to solve this, but I don't know how, any help will be really appreciated. (the attached image shows my problem) thanks, Esteban

4 4

[Pharo-project] ODBC suggestion
by Schwab,Wilhelm K Feb. 1, 2012

Feb. 1, 2012

Hello all, For alien/callbacks, it seems I should leave 1.1.1 behind - it's been a very nice release. Migrate (my answer to not losing code) flagged a few methods. One looks like it might be of wide interest: moduleName "Return the name of the module for this library" SmalltalkImage current platformName = 'Win32' ifTrue: [ ^ 'odbc32' ]. SmalltalkImage current platformName = 'unix' ifTrue: [ ^ 'libodbc.so' ]. ^ self error: 'Don''t know the ODBC library name' What do you think? Stef, this is why I don't like putting the module name in the pragmas. Does that make sense? Bill

1 0

[Pharo-project] **Important** Pharo Conference Call for Date Feedback
by StÃ©phane Ducasse Feb. 1, 2012

Feb. 1, 2012

Hi guys We want to organize a Pharo Conference @ lille around business and companies in May/June 2012. Now we need you to understand what is the best to organize because we have some constraints (like not good access to rooms on saturday). Could you reply to the following questions: Are you planning to attend: Yes No Would you attend two days: Yes No Would you like to present something: Yes No Would you prefer to have (remove the one you do not like) - one friday and one saturday or - two days during the week would be not a problem. Would you like to have Handons: Yes No Business/Experience returns: Yes No What are the following dates that are ok for you? Frid 11- Satur 12 May 2012: Yes No Thur 10- Frid 11 May 2012: Yes No Mond 14- Tuesd 15 May 2012: Yes No Tuesd 15- Wedn 16 May 2012: Yes No Thur 24 - Frid 25 May 2012: Yes No Frid 25- Satur 26 May 2012: Yes No Stef

1 1

[Pharo-project] CogVM driver vs executable
by Sven Van Caekenberghe Jan. 31, 2012

Jan. 31, 2012

In response to my posting http://lists.gforge.inria.fr/pipermail/pharo-project/2012-January/058790.ht… I got feedback from people trying to use SSL with Eliot's CogVM http://www.mirandabanda.org/files/Cog/VM/VM.r2522/coglinux.tgz instead of the Pharo one that I normally use http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip They reported that it did not work for them. So I tried this myself on my Ubuntu 11.10 (GNU/Linux 3.0.0-14-virtual i686) server and yes it fails with 'can't infer base LD_LIBRARY_PATH. Aborting.' which was discussed in this list before. I am not qualified to really understand those discussions. But when I used the executable 'inside' coglinux/lib/squeak/4.0-2522/squeak everything worked as expected. So the question is what does the driver (I don't know if that is the right word) coglinux/squeak or coglinux/bin/squeak do ? Since the pharo variant seems to operate fine without it, do we need the driver ? Sven

4 7

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?
by Janko MivÅ¡ek Jan. 31, 2012

Jan. 31, 2012

-------- Prvotno sporoÄilo -------- Datum: Tue, 31 Jan 2012 07:54:58 -0600 Od: Peter Hunsberger <peter.hunsberger(a)gmail.com> With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience: I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements. Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well. Now onto the main question posed here.... I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk. Peter Hunsberger On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: 200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :) Laurent 2012/1/28 Janko MivÅ¡ek <janko.mivsek(a)eranova.si <mailto:janko.mivsek@eranova.si>> Hi guys, Ralph Johnson in his InfoQ interview made an interesting observation: 2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... " Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)? Are we really not able to scale to bigger projects/systems because of that? Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still... [1] http://www.infoq.com/interviews/johnson-armstrong-oop Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?
by Janko MivÅ¡ek Jan. 31, 2012

Jan. 31, 2012

-------- Prvotno sporoÄilo -------- Datum: Tue, 31 Jan 2012 10:07:34 -0800 Od: Jon Paynter <kittle31(a)gmail.com> > Dear Niall, > Thanks for comprehensive report, the biggest project reported so far. > I forwarded it to Squeak and Pharo mailing lists. > Has anyone data for other big Smalltalk projects/systems, like OOCL > etc? OOCL has 2 smalltalk projects The small one with 2,200 classes and 2 developers The larger one ranged from 20-50 developers (my guess), and currently has 24,000 classes. And the last time it was measured (a few years ago) we had around 8million lines of code. And my own personal $0.02 on productivity: One place I worked at as a contractor was a java shop. I was just learning java, so my skills at that time were lousy. We had a small project to do, and I managed to get 2 weeks of time from the local java expert. She came highly recommended by everyone, and after watching her work, she was in deed VERY good. After 2 weeks of struggle, we failed to finish the project. Afterwards, I sat down and did the project in visualworks ( from scratch) in 1 day. Experience matters, but using the right tool for the job is where its at.

1 0