[Pharo-project] "Do not feed the trolls"
From Wikipedia:
In Internet slang, a troll is someone who posts inflammatory,[2] extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking readers into an emotional response[3] or of otherwise disrupting normal on-topic discussion.[4] The noun troll may refer to the provocative message itself, as in: "That was an excellent troll you posted".
Tnx for the flowers! Ok, lets resume, what we did see from the Pharo team since Pharo 1.0, 15. April 2010: Much advanced code. Yes. But - what for? Any *important* app outside there? Dr.Geo ... any parametric CAD can do this! CMSBOX - pfffft! How many customers? Pharo - still unstable, unusable, no sponsors. Jitter? Hmmm... e.g. LUAJit *has* sponsors, *very* mighty sponsors, WoW, Wikipedia ... and it *ins* rock stable, portable to 32bit, 64bit Intel, PPC *and* ARM!!! One man show, b.t.w.!! Like Elliot Miranda with COGVM! Develop the development process! tnx for seeing reality, Guido Stepken Am 21.02.2012 02:00 schrieb "Dale Henrichs" <dhenrich@vmware.com>:
From Wikipedia:
In Internet slang, a troll is someone who posts inflammatory,[2] extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking readers into an emotional response[3] or of otherwise disrupting normal on-topic discussion.[4] The noun troll may refer to the provocative message itself, as in: "That was an excellent troll you posted".
Develop the development process!
You keep saying this, but you don't explain what you mean. You think Pharo's development process is flawed. Ok, we get that. But what exactly do you suggest be done about it? To be clear - I am _not_ asking to hear what's _wrong_ with it. I want to hear a positive suggestion of something that can be done. Something practical and possible. Once given that, Stephane and the others can either use the information, or not. But either way you will have said your piece and there will be no need to say any more.
+10. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stuart Herring [st-lists@stuartherring.com] Sent: Monday, February 20, 2012 9:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] "Do not feed the trolls"
Develop the development process!
You keep saying this, but you don't explain what you mean. You think Pharo's development process is flawed. Ok, we get that. But what exactly do you suggest be done about it? To be clear - I am _not_ asking to hear what's _wrong_ with it. I want to hear a positive suggestion of something that can be done. Something practical and possible. Once given that, Stephane and the others can either use the information, or not. But either way you will have said your piece and there will be no need to say any more.
Guido Stepken wrote
Much advanced code. Yes. But - what for? Any *important* app outside there? Dr.Geo ... any parametric CAD can do this! CMSBOX - pfffft! How many customers?
Pharo - still unstable, unusable, no sponsors.
Jitter? Hmmm... e.g. LUAJit *has* sponsors, *very* mighty sponsors, WoW, Wikipedia ... and it *ins* rock stable, portable to 32bit, 64bit Intel, PPC *and* ARM!!!
One man show, b.t.w.!! Like Elliot Miranda with COGVM!
Develop the development process!
tnx for seeing reality,
Guido Stepken
I guess I need now to thank you too for your flowers... It is not up to me whether our CMSBOX is an important project in a general context. But to answer your question: almost 500 customers in Switzerland are using this Pharo-based application until now and for them, this application and the underlying very stable technology with ongoing development IS important. Besides, we at netstyle.ch created several business critical web-based applications, from automatic inventory management to a large CRM for a Swiss insurance broker. Although you probably never heard of these applications I guess we are nevertheless an important component of the Pharo eco system and we use it because we believe it to be the right way of the ongoing development. Although there is always room for improvement, the migration to Pharo was and is an important step within our company strategy. On this basis, we built a company from scratch with more than 10 employees whereof five software engineers are doing nothing else than working with the Pharo IDE. It is due to the ongoing development of a small community that our personal "success" became possible. Could not be more thankful for that! Keep the work going! To now improve whatever needs to improved in your opinion, one should not issue orders to or offend the community but to collaborate constructively on suggestions. Honestly, this was not our strength within the past months too, but we are willing to support this lively community as much as we can in the future although we are not Wikipedia or similar. I am convinced that a constructive and appreciative collaboration is the only way to improve Pharo so please consider my words when writing your next message. Cheers, Chris Wysseier Founder and CEO of netstyle.ch and cmsbox P.S: Also wanted to say hi to everybody as I am new on the list. Be aware that I am not an *experienced* software engineer (let's say "anymore" ;) ) and therefore will not be able to discuss on technical strategies or tasks. But I would like to know what is going on and to show support and presence to all of you. -- View this message in context: http://forum.world.st/Do-not-feed-the-trolls-tp4405636p4406708.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Chris, Thank you very much for your experience report and I think I'm not alone to like to hear from your more about what are your wishes as a manager from the Pharo in the future. Because you are an "enterprise" (in a positive meaning of that word) Pharo user. Maybe let me start asking you an opinion of what I'd like to see from Pharo as a priority: - more stability, - better user experience (UX), - better version control and packaging tools - better integration of tools - tabbed browsing, back button etc More polishing and boring bug hunting tasks therefore and just a bit less fundamental rewritings like compiler etc. Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the above priorities are much more important. Best regards Janko S, wysseier piše:
Guido Stepken wrote
Much advanced code. Yes. But - what for? Any *important* app outside there? Dr.Geo ... any parametric CAD can do this! CMSBOX - pfffft! How many
I guess I need now to thank you too for your flowers...
It is not up to me whether our CMSBOX is an important project in a general context. But to answer your question: almost 500 customers in Switzerland are using this Pharo-based application until now and for them, this application and the underlying very stable technology with ongoing development IS important. Besides, we at netstyle.ch created several business critical web-based applications, from automatic inventory management to a large CRM for a Swiss insurance broker. Although you probably never heard of these applications I guess we are nevertheless an important component of the Pharo eco system and we use it because we believe it to be the right way of the ongoing development.
Although there is always room for improvement, the migration to Pharo was and is an important step within our company strategy. On this basis, we built a company from scratch with more than 10 employees whereof five software engineers are doing nothing else than working with the Pharo IDE. It is due to the ongoing development of a small community that our personal "success" became possible. Could not be more thankful for that! Keep the work going!
To now improve whatever needs to improved in your opinion, one should not issue orders to or offend the community but to collaborate constructively on suggestions. Honestly, this was not our strength within the past months too, but we are willing to support this lively community as much as we can in the future although we are not Wikipedia or similar. I am convinced that a constructive and appreciative collaboration is the only way to improve Pharo so please consider my words when writing your next message.
Cheers,
Chris Wysseier Founder and CEO of netstyle.ch and cmsbox
P.S: Also wanted to say hi to everybody as I am new on the list. Be aware that I am not an *experienced* software engineer (let's say "anymore" ;) ) and therefore will not be able to discuss on technical strategies or tasks. But I would like to know what is going on and to show support and presence to all of you.
-- View this message in context: http://forum.world.st/Do-not-feed-the-trolls-tp4405636p4406708.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On Feb 21, 2012, at 07:07, Janko Mivšek wrote:
- more stability,
This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo. I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: crash ^self crash + 4 and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8. The 1.3 says: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13307] How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help? Thanks for everybody's efforts! ../Dave
yeah I agree that would be great if a debugger would popup there... On 2012-02-21, at 15:34, Dave Mason wrote:
On Feb 21, 2012, at 07:07, Janko Mivšek wrote:
- more stability,
This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo.
I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: crash ^self crash + 4 and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8. The 1.3 says: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13307]
How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help?
Thanks for everybody's efforts!
../Dave
Hi Dave, On 21 Feb 2012, at 15:34, Dave Mason wrote:
This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo.
I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: crash ^self crash + 4 and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8. The 1.3 says: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13307]
How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help?
Thanks for everybody's efforts!
../Dave
Out of the box experience is indeed very important. There was an important fix related to stopping infinite loops recently, I am sure the latest 1.4 includes it. Sven
Having talked about this many times earlier, i have now codified for the system that has impediment to using toggle breakpoint, halts in polling methods, kernel , system classes etc.. saving the file after any runtime execution of Pharo.. I do have personally a stable env now with 1.3 on ubuntu but on windows though a big improvement now, it still stack overflows more due to a basic mistake no experienced small talker commits viz putting a halt in a polling method, System classes etc.. , modifying a code that is invoked every millisecond in say mouseDown: or the ilk. What is needed is a very simple Pharo kernel, that has this safe mode on, which disallows for a fresher the mistakes which bites.... Not Feb 21, 2012, at 8:24 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Hi Dave,
On 21 Feb 2012, at 15:34, Dave Mason wrote:
This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo.
I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: crash ^self crash + 4 and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8. The 1.3 says: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13307]
How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help?
Thanks for everybody's efforts!
../Dave
Out of the box experience is indeed very important.
There was an important fix related to stopping infinite loops recently, I am sure the latest 1.4 includes it.
Sven
On Feb 21, 2012, at 3:34 PM, Dave Mason wrote:
On Feb 21, 2012, at 07:07, Janko Mivšek wrote:
- more stability,
This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo.
I have may be a crash per month or so at the maximum and even in this case I'm doing something nasty. and nobody in our team experience that. Pharo is crashing less than my mac email client! You should report that as soon as you get it.
I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: crash ^self crash + 4 and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8.
really?
The 1.3 says: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13307]
How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help?
This is really strange.
Thanks for everybody's efforts!
../Dave
Hi janko
More polishing and boring bug hunting tasks therefore and just a bit less fundamental rewritings like compiler etc.
Did you ever look at one bug entry? You see the bug entry does not magically empty itself. There are people like me and marcus and a couple of others that are looking at reports, producing fixes...
Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the above priorities are much more important.
Well this is not true: - if you want to build the next generation of code coverage tools - better tools - without a good compiler we can also say bye bye to the next generation of optimization do not think that Cog is the end of the story. It is just the start. then you need to be able to understand the code and be able to fix it. So the compiler is important. Stef
True. Again, there are two opposing forces: compatibility versus improvement. Sometimes it is very hard or even impossible to improve system without breaking compatibility. What i don't see, is how things which lying in front of us are related to any sort of academia research. They are completely practical: - improve event handling - move to new file system - provide better FFI - new compiler and so on. You know, Janko, polishing makes sense if you have something which looks fine and you know that it will serve you well in future. But polishing things which were lying broken in garage for years makes little sense. People might mistakenly think that we wanna change things solely for the sake of change. But it is not like that. We need these changes , need to fix our infrastructure, because without solid basement you cannot build anything good. On 21 February 2012 22:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi janko
More polishing and boring bug hunting tasks therefore and just a bit less fundamental rewritings like compiler etc.
Did you ever look at one bug entry? You see the bug entry does not magically empty itself. There are people like me and marcus and a couple of others that are looking at reports, producing fixes...
Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the above priorities are much more important.
Well this is not true:     - if you want to build the next generation of code coverage tools     - better tools     - without a good compiler we can also say bye bye to the next generation of optimization     do not think that Cog is the end of the story. It is just the start.
then you need to be able to understand the code and be able to fix it. So the compiler is important.
Stef
-- Best regards, Igor Stasenko.
People might mistakenly think that we wanna change things solely for the sake of change. But it is not like that. We need these changes , need to fix our infrastructure, because without solid basement you cannot build anything good.
Thanks Igor. Let us take a concrete example. I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important. If you happen to know how we can get this code plug and play let me know :) but I guess that you will not easily. But really read it! Really read it it is worth the 2 min you can people vs the days giro and me are spending there (and this is not about just coding but understanding the situation and building a better one). Because we are far from doing stuff for research. We are not doing research in interaction design! I could show you some of the compiler code too. Stef HandMorph>>handleEvent: anEvent | evt ofs | owner ifNil:[^self]. evt := anEvent. self logEventStats: evt. evt isMouse ifTrue:[ "just for record, to be used by capture block" lastMouseEvent := evt]. captureBlock ifNotNil: [ ^ captureBlock value: anEvent ]. evt isMouseOver ifTrue:[^self sendMouseEvent: evt]. self showDebugEvent: evt. "Notify listeners" self sendListenEvent: evt to: self eventListeners. evt isWindowEvent ifTrue: [ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isKeyboard ifTrue:[ self sendListenEvent: evt to: self keyboardListeners. self sendKeyboardEvent: evt. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isDropEvent ifTrue:[ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isMouse ifTrue:[ self sendListenEvent: evt to: self mouseListeners. lastMouseEvent := evt]. "Check for pending drag or double click operations." mouseClickState ifNotNil:[ (mouseClickState handleEvent: evt from: self) ifFalse:[ "Possibly dispatched #click: or something and will not re-establish otherwise" ^self mouseOverHandler processMouseOver: lastMouseEvent]]. evt isMove ifTrue:[ self position: evt position. self sendMouseEvent: evt. ] ifFalse:[ "Issue a synthetic move event if we're not at the position of the event" (evt position = self position) ifFalse:[self moveToEvent: evt]. "Drop submorphs on button events" (self hasSubmorphs) ifTrue:[self dropMorphs: evt] ifFalse:[self sendMouseEvent: evt]. ]. self showMouseFocusEvent: evt. self mouseOverHandler processMouseOver: lastMouseEvent. HandMorph>>processEvents "Process user input events from the local input devices." | evt evtBuf type hadAny | ActiveEvent ifNotNil: ["Meaning that we were invoked from within an event response. Make sure z-order is up to date" self mouseOverHandler processMouseOver: lastMouseEvent]. hadAny := false. [(evtBuf := Sensor nextEvent) isNil] whileFalse: [evt := nil. "for unknown event types" type := evtBuf first. type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt := self generateMouseEvent: evtBuf]. type = EventTypeKeyboard ifTrue: [recentModifiers := evtBuf fifth. evt := self generateKeyboardEvent: evtBuf]. type = EventTypeDragDropFiles ifTrue: [evt := self generateDropFilesEvent: evtBuf]. type = EventTypeWindow ifTrue:[evt := self generateWindowEvent: evtBuf]. "All other events are ignored" (type ~= EventTypeDragDropFiles and: [evt isNil]) ifTrue: [^self]. evt isNil ifFalse: ["Finally, handle it" self handleEvent: evt. hadAny := true. "For better user feedback, return immediately after a mouse event has been processed." (evt isMouse and: [evt isMouseWheel not]) ifTrue: [^self]]]. "note: if we come here we didn't have any mouse events" mouseClickState notNil ifTrue: ["No mouse events during this cycle. Make sure click states time out accordingly" mouseClickState handleEvent: lastMouseEvent asMouseMove from: self]. hadAny ifFalse: ["No pending events. Make sure z-order is up to date" self mouseOverHandler processMouseOver: lastMouseEvent] HandMorph>>generateMouseEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | position buttons modifiers type trail stamp oldButtons evtChanged | evtBuf first = lastEventBuffer first ifTrue: ["Workaround for Mac VM bug, *always* generating 3 events on clicks" evtChanged := false. 3 to: evtBuf size do: [:i | (lastEventBuffer at: i) = (evtBuf at: i) ifFalse: [evtChanged := true]]. evtChanged ifFalse: [^nil]]. stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. position := evtBuf third @ evtBuf fourth. buttons := evtBuf fifth. modifiers := evtBuf sixth. type := buttons = 0 ifTrue: [lastEventBuffer fifth = 0 ifTrue: [#mouseMove] ifFalse: [#mouseUp]] ifFalse: [lastEventBuffer fifth = 0 ifTrue: [#mouseDown] ifFalse: [#mouseMove]]. buttons := buttons bitOr: (modifiers bitShift: 3). oldButtons := lastEventBuffer fifth bitOr: (lastEventBuffer sixth bitShift: 3). lastEventBuffer := evtBuf. type == #mouseMove ifTrue: [trail := self mouseTrailFrom: evtBuf. ^MouseMoveEvent basicNew setType: type startPoint: (self position) endPoint: trail last trail: trail buttons: buttons hand: self stamp: stamp]. ^MouseButtonEvent basicNew setType: type position: position which: (oldButtons bitXor: buttons) buttons: buttons hand: self stamp: stamp
"mouseOverHandler" is *absolutely* depreciated everywhere, iOS, Android AND Windows 8 ... tablet useforms dominate Desktop useforms more and more. just my 2ct. Am 22.02.2012 08:32 schrieb "Stéphane Ducasse" <stephane.ducasse@inria.fr>:
People might mistakenly think that we wanna change things solely for the sake of change. But it is not like that. We need these changes , need to fix our infrastructure, because without solid basement you cannot build anything good.
Thanks Igor. Let us take a concrete example. I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important. If you happen to know how we can get this code plug and play let me know :) but I guess that you will not easily.
But really read it! Really read it it is worth the 2 min you can people vs the days giro and me are spending there (and this is not about just coding but understanding the situation and building a better one). Because we are far from doing stuff for research. We are not doing research in interaction design!
I could show you some of the compiler code too.
Stef
HandMorph>>handleEvent: anEvent | evt ofs | owner ifNil:[^self]. evt := anEvent. self logEventStats: evt.
evt isMouse ifTrue:[ "just for record, to be used by capture block" lastMouseEvent := evt].
captureBlock ifNotNil: [ ^ captureBlock value: anEvent ]. evt isMouseOver ifTrue:[^self sendMouseEvent: evt].
self showDebugEvent: evt.
"Notify listeners" self sendListenEvent: evt to: self eventListeners.
evt isWindowEvent ifTrue: [ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent].
evt isKeyboard ifTrue:[ self sendListenEvent: evt to: self keyboardListeners. self sendKeyboardEvent: evt. ^self mouseOverHandler processMouseOver: lastMouseEvent].
evt isDropEvent ifTrue:[ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent].
evt isMouse ifTrue:[ self sendListenEvent: evt to: self mouseListeners. lastMouseEvent := evt].
"Check for pending drag or double click operations." mouseClickState ifNotNil:[ (mouseClickState handleEvent: evt from: self) ifFalse:[ "Possibly dispatched #click: or something and will not re-establish otherwise" ^self mouseOverHandler processMouseOver: lastMouseEvent]].
evt isMove ifTrue:[ self position: evt position. self sendMouseEvent: evt. ] ifFalse:[ "Issue a synthetic move event if we're not at the position of the event" (evt position = self position) ifFalse:[self moveToEvent: evt]. "Drop submorphs on button events" (self hasSubmorphs) ifTrue:[self dropMorphs: evt] ifFalse:[self sendMouseEvent: evt]. ]. self showMouseFocusEvent: evt. self mouseOverHandler processMouseOver: lastMouseEvent.
HandMorph>>processEvents "Process user input events from the local input devices."
| evt evtBuf type hadAny | ActiveEvent ifNotNil: ["Meaning that we were invoked from within an event response. Make sure z-order is up to date"
self mouseOverHandler processMouseOver: lastMouseEvent]. hadAny := false. [(evtBuf := Sensor nextEvent) isNil] whileFalse: [evt := nil. "for unknown event types" type := evtBuf first. type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt := self generateMouseEvent: evtBuf]. type = EventTypeKeyboard ifTrue: [recentModifiers := evtBuf fifth. evt := self generateKeyboardEvent: evtBuf]. type = EventTypeDragDropFiles ifTrue: [evt := self generateDropFilesEvent: evtBuf]. type = EventTypeWindow ifTrue:[evt := self generateWindowEvent: evtBuf]. "All other events are ignored" (type ~= EventTypeDragDropFiles and: [evt isNil]) ifTrue: [^self]. evt isNil ifFalse: ["Finally, handle it"
self handleEvent: evt. hadAny := true.
"For better user feedback, return immediately after a mouse event has been processed." (evt isMouse and: [evt isMouseWheel not]) ifTrue: [^self]]]. "note: if we come here we didn't have any mouse events" mouseClickState notNil ifTrue: ["No mouse events during this cycle. Make sure click states time out accordingly"
mouseClickState handleEvent: lastMouseEvent asMouseMove from: self]. hadAny ifFalse: ["No pending events. Make sure z-order is up to date"
self mouseOverHandler processMouseOver: lastMouseEvent]
HandMorph>>generateMouseEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer"
| position buttons modifiers type trail stamp oldButtons evtChanged | evtBuf first = lastEventBuffer first ifTrue: ["Workaround for Mac VM bug, *always* generating 3 events on clicks"
evtChanged := false. 3 to: evtBuf size do: [:i | (lastEventBuffer at: i) = (evtBuf at: i) ifFalse: [evtChanged := true]]. evtChanged ifFalse: [^nil]]. stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. position := evtBuf third @ evtBuf fourth. buttons := evtBuf fifth. modifiers := evtBuf sixth. type := buttons = 0 ifTrue: [lastEventBuffer fifth = 0 ifTrue: [#mouseMove] ifFalse: [#mouseUp]] ifFalse: [lastEventBuffer fifth = 0 ifTrue: [#mouseDown] ifFalse: [#mouseMove]]. buttons := buttons bitOr: (modifiers bitShift: 3). oldButtons := lastEventBuffer fifth bitOr: (lastEventBuffer sixth bitShift: 3). lastEventBuffer := evtBuf. type == #mouseMove ifTrue: [trail := self mouseTrailFrom: evtBuf. ^MouseMoveEvent basicNew setType: type startPoint: (self position) endPoint: trail last trail: trail buttons: buttons hand: self stamp: stamp]. ^MouseButtonEvent basicNew setType: type position: position which: (oldButtons bitXor: buttons) buttons: buttons hand: self stamp: stamp
Dear Stef Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications. Or did I misinterpret your intention? Cheers, Chris
Hi Christoph! Jobs dropped FLASH for several important reasons: 1. Too much polling in there. Processor load was high, eating up batteries. 2. Flash games with "onMouseOver" can't run on tablets. 3. Event model was so oldfashioned, that Adobe decided to drop the VM. FLASH was the most successful virtual machine ever, hundreds of thousands of applications, billions of users, dominating the whole market. Dead within only 2 years! Severe marketing and technical design mistakes by the Adobe management, IMHO. Pharo suffers similar problems: GUI is not tablet-ready. Compare to Android 4.0: Android has joined the 2.3 line for mobiles with tablet line and has invested much much brainpower in finding out, how apps can be designed, that they can comfortably be used on different resolutions, portrait as well as landscape. Well done IMHO, even suited for desktop apps. Pharo also has too much polling code, is eating up batteries as well. As long as Apple does not allow fullsized interpreters in Appstore, there is definitely no chance ever for Pharo to be brought onto tablet. I see no chances for Pharo on ARM, Tablets, whatever ... never ever! This increasing market with hundreds of millions hardware units is completely lost for Smalltalkers, once again. Tablet apps will very soon even dominate the desktop market! regards, Guido Stepken Am 22.02.2012 09:39 schrieb "Christoph Wysseier" <c.wysseier@netstyle.ch>:
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
Or did I misinterpret your intention?
Cheers,
Chris
Pharo is an IDE. IDEs don't run on tablets. On 22 February 2012 10:06, Guido Stepken <gstepken@googlemail.com> wrote:
Hi Christoph!
Jobs dropped FLASH for several important reasons:
1. Too much polling in there. Processor load was high, eating up batteries. 2. Flash games with "onMouseOver" can't run on tablets. 3. Event model was so oldfashioned, that Adobe decided to drop the VM.
FLASH was the most successful virtual machine ever, hundreds of thousands of applications, billions of users, dominating the whole market.
Dead within only 2 years! Severe marketing and technical design mistakes by the Adobe management, IMHO.
Pharo suffers similar problems: GUI is not tablet-ready. Compare to Android 4.0: Android has joined the 2.3 line for mobiles with tablet line and has invested much much brainpower in finding out, how apps can be designed, that they can comfortably be used on different resolutions, portrait as well as landscape. Well done IMHO, even suited for desktop apps.
Pharo also has too much polling code, is eating up batteries as well.
As long as Apple does not allow fullsized interpreters in Appstore, there is definitely no chance ever for Pharo to be brought onto tablet.
I see no chances for Pharo on ARM, Tablets, whatever ... never ever!
This increasing market with hundreds of millions hardware units is completely lost for Smalltalkers, once again.
Tablet apps will very soon even dominate the desktop market!
regards, Guido Stepken Am 22.02.2012 09:39 schrieb "Christoph Wysseier" <c.wysseier@netstyle.ch
:
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
Or did I misinterpret your intention?
Cheers,
Chris
-- Milan Mimica http://sparklet.sf.net
2012/2/22 Tobias Pape <Das.Linux@gmx.de>
Am 2012-02-22 um 10:30 schrieb Milan Mimica:
Pharo is an IDE. IDEs don't run on tablets.
Then see the lively kernelâ¦
Another example could be WaveMaker, a complete development IDE running in the browser.
Pharo can and does run beautifully on much lesser hardware requirement than Android does. Combine Pharo with tiny core linux or put it on top of Raspberry Pi.. I am sure for a 128 MB RAM, 256MB Pharo can offer the best experience. We may have a need to optimize the performance etc.. but that is work underway and I am sure in another year we will have something workable. Even if not, provided a good enterprise funding it can be done in less time than it took to get Android to shape. Future will obviously provide 1GB RAM Tablet at 60$ or less.. but not visibly in the next couple of years.. We should push for adoption in these yet available opportunities of linux variants, Raspberry pi to offer a cleaner / leaner Pharo Kernel. As for all the predictions of Web taking over, I have yet to comprehend Web as a means to have best user experience. It offers a major advantage of all of the server processing with just the client view presentation or minimal view code on the browser, but if you look at Gmail with ever increasing javascript base, the Dart, the HTML 5 elements specially the sqllite, video tag, canvas, it is just slowly converting browsers to general purpose presentation engine, with as much power of desktop app. But this generalization of presentation will remain a compromise. I for one do believe that server side focus though is very important for Pharo, the desktop is where with Morphic cleaned up, multi touch enabled, Open GL integration, newer paradigm of interactive user interface blurring the line of dev/ runtime, complete flexibility, ductile, elastic.. throw in all adjectives it can throw open a totally new frontier. This is all not tablets, multi touch will rule all of large screen displays in future from banks, hospitals to any place. Useful greatly for medical presentations, manipulations, but equally usable in corporate world of the future.. Segregate the concept of server side from delivering web browser apps. That is a bit of enterprise fallacy. Yes nice in social context, but I do believe its been a marketing overkill to make browsers the default client for enterprise, but half driven by drabness of widgetry from Java world and the complexity of the Windows UI toolkit. Still the richness of widgets on a GUI app is not trifling work to replicate in a web and we can easily do a client-server app with all the business executed on the server and / or agent network delivery of parcelled code sections that clients trade with and complete their tasks. This code section transfer can be same model as the javascript transfers on a browser. Web has as yet not delivered on its promises for Office Suite, even a comparable email client to Outlook, Thunderbird and others.. it may have killed also rans of the past but not comparable to feature / capability of desktop. I doubt if I will ever see MS Office vanish.. perhaps Star Office is the only alternative but not web really. photo viewing the most ubiquitous of web apps, are a pain developing compared to a morphic app if we indulge ourselves in.. ,Yes it will require a year or more of effort coming up with ecquvivalents to javascript libraries.. but when done, or lets say custom done it is neater, easier , flexible than using those libraries. I do not rate Picassa as great.. at all, with morphic you can have all jazz custom built as in flash but lot more fun.. I forsee, the possibility given a good start up with decent funds, can work out more out of Morphic in couple of years, that can make desktop the fun place to be in.. Why not think of Pharo on the TV screen/ other such devices to present all the complex UI's, menu's that are primarily morphic widgets that get you through to playing the streaming video, disks et all.. but all of its UI layer can easily be a fun work with Morphic.. it can offer all the fun of twisting morphs, decorated and intelligent morphs placed/ floating / animation or whatever is your raging thought.. on these large screens.. Of course I wish we could ensure perfection in rendering a la Cuis. for that to be not just fun but perfect. Look at all the devices that are in hospitals that do cry for a UI revamp, I am sure with half decent effort we can make the UI on devices greater fun..for everyone, the user, the developer and ofcourse the enterprise making money, than what we see in there. All of PoS apps in VB and its ilk.. are generation old, With my little dev interface I have now cobbled up with three Worlds/ Panels, I have seen a glint in the eyes of the newbies that they are working on something ahead of the current world, but the crashes, glitches do get them doubting..!, which I intend to smoothen and even cloak around a bit so that they do not feel the rough edges unless they are experienced smalltalkers to comprehend all of it. On Wed, Feb 22, 2012 at 3:15 PM, Tobias Pape <Das.Linux@gmx.de> wrote:
Am 2012-02-22 um 10:30 schrieb Milan Mimica:
Pharo is an IDE. IDEs don't run on tablets.
Then see the lively kernelâ¦
what kind of devices are using raspberry pi? I would like to see the physical size of such devices. On Feb 22, 2012, at 6:30 PM, S Krish wrote:
tiny core linux or put it on top of Raspberry Pi.. I am sure for a 128 MB RAM, 256MB Pharo can offer the best experience.
Hello Sudhakar, I totally agree. I believe we can build the future we want. And if we don't, we deserve to get what others provide or envision for us. I believe we can deliver a better experience as a client, and a better developer experience as a server. I personally don't know of anything that approaches Smalltalk for a comprehensive experience. With appropriate funding, we can accomplish great things. And without it, we are better than most. First, we can envision things that others do not have the worldview to be able to envision. It always frustrates me whenever I have to restart an OS, or an app because of some software update. Ugh! Really ..., this is 2012 and we can't do better. I believe Pharo has a great future and I hope to contribute. And the nice thing is, that we can do web apps as well as, or better than others. We also can improve our UI abilities and do better than others there. We can cover both worlds quite well. Just my opinion. Jimmie On 2/22/2012 11:30 AM, S Krish wrote:
Pharo can and does run beautifully on much lesser hardware requirement than Android does.
Combine Pharo with tiny core linux or put it on top of Raspberry Pi.. I am sure for a 128 MB RAM, 256MB Pharo can offer the best experience.
We may have a need to optimize the performance etc.. but that is work underway and I am sure in another year we will have something workable. Even if not, provided a good enterprise funding it can be done in less time than it took to get Android to shape.
Future will obviously provide 1GB RAM Tablet at 60$ or less.. but not visibly in the next couple of years.. We should push for adoption in these yet available opportunities of linux variants, Raspberry pi to offer a cleaner / leaner Pharo Kernel.
As for all the predictions of Web taking over, I have yet to comprehend Web as a means to have best user experience. It offers a major advantage of all of the server processing with just the client view presentation or minimal view code on the browser, but if you look at Gmail with ever increasing javascript base, the Dart, the HTML 5 elements specially the sqllite, video tag, canvas, it is just slowly converting browsers to general purpose presentation engine, with as much power of desktop app. But this generalization of presentation will remain a compromise.
I for one do believe that server side focus though is very important for Pharo, the desktop is where with Morphic cleaned up, multi touch enabled, Open GL integration, newer paradigm of interactive user interface blurring the line of dev/ runtime, complete flexibility, ductile, elastic.. throw in all adjectives it can throw open a totally new frontier.
This is all not tablets, multi touch will rule all of large screen displays in future from banks, hospitals to any place. Useful greatly for medical presentations, manipulations, but equally usable in corporate world of the future..
Segregate the concept of server side from delivering web browser apps. That is a bit of enterprise fallacy. Yes nice in social context, but I do believe its been a marketing overkill to make browsers the default client for enterprise, but half driven by drabness of widgetry from Java world and the complexity of the Windows UI toolkit. Still the richness of widgets on a GUI app is not trifling work to replicate in a web and we can easily do a client-server app with all the business executed on the server and / or agent network delivery of parcelled code sections that clients trade with and complete their tasks. This code section transfer can be same model as the javascript transfers on a browser.
Web has as yet not delivered on its promises for Office Suite, even a comparable email client to Outlook, Thunderbird and others.. it may have killed also rans of the past but not comparable to feature / capability of desktop. I doubt if I will ever see MS Office vanish.. perhaps Star Office is the only alternative but not web really.
photo viewing the most ubiquitous of web apps, are a pain developing compared to a morphic app if we indulge ourselves in.. ,Yes it will require a year or more of effort coming up with ecquvivalents to javascript libraries.. but when done, or lets say custom done it is neater, easier , flexible than using those libraries. I do not rate Picassa as great... at all, with morphic you can have all jazz custom built as in flash but lot more fun..
I forsee, the possibility given a good start up with decent funds, can work out more out of Morphic in couple of years, that can make desktop the fun place to be in..
Why not think of Pharo on the TV screen/ other such devices to present all the complex UI's, menu's that are primarily morphic widgets that get you through to playing the streaming video, disks et all.. but all of its UI layer can easily be a fun work with Morphic.. it can offer all the fun of twisting morphs, decorated and intelligent morphs placed/ floating / animation or whatever is your raging thought.. on these large screens.. Of course I wish we could ensure perfection in rendering a la Cuis. for that to be not just fun but perfect.
Look at all the devices that are in hospitals that do cry for a UI revamp, I am sure with half decent effort we can make the UI on devices greater fun..for everyone, the user, the developer and ofcourse the enterprise making money, than what we see in there. All of PoS apps in VB and its ilk.. are generation old,
With my little dev interface I have now cobbled up with three Worlds/ Panels, I have seen a glint in the eyes of the newbies that they are working on something ahead of the current world, but the crashes, glitches do get them doubting..!, which I intend to smoothen and even cloak around a bit so that they do not feel the rough edges unless they are experienced smalltalkers to comprehend all of it.
On Feb 22, 2012, at 10:18 PM, Jimmie Houchin wrote:
Hello Sudhakar,
I totally agree. I believe we can build the future we want. And if we don't, we deserve to get what others provide or envision for us. YES YES YES and YES
I believe we can deliver a better experience as a client, and a better developer experience as a server. I personally don't know of anything that approaches Smalltalk for a comprehensive experience.
With appropriate funding, we can accomplish great things. And without it, we are better than most. First, we can envision things that others do not have the worldview to be able to envision.
It always frustrates me whenever I have to restart an OS, or an app because of some software update. Ugh! Really ..., this is 2012 and we can't do better. I believe Pharo has a great future and I hope to contribute.
And the nice thing is, that we can do web apps as well as, or better than others. We also can improve our UI abilities and do better than others there. We can cover both worlds quite well.
Just my opinion.
Jimmie
Am 22.02.2012 10:31 schrieb "Milan Mimica" <milan.mimica@gmail.com>:
Pharo is an IDE. IDEs don't run on tablets.
You're right so far. Principally IDEs best run on desktop computers. I tried several new concepts to develop on tablet (Bluetooth keyboard, mouse) during travels: Jens Moenig's ELEMENTS: http://www.chirp.scratchr.org/blog/?p=24 Fun seeing Smalltalk code in colored blocks, pushing them around like in EToys, generating/refactoring code. Much better designed, because of LISP + OpenGL is: http://blocky.io See the videos. Blocky makes no difference between Morphs and Code. This is pure fun, developing programs, games on tablet, and its incredibly fast! Have fun! Guido Stepken
On 22 February 2012 10:06, Guido Stepken <gstepken@googlemail.com> wrote:
Hi Christoph!
Jobs dropped FLASH for several important reasons:
1. Too much polling in there. Processor load was high, eating up
batteries.
2. Flash games with "onMouseOver" can't run on tablets. 3. Event model was so oldfashioned, that Adobe decided to drop the VM.
FLASH was the most successful virtual machine ever, hundreds of thousands of applications, billions of users, dominating the whole market.
Dead within only 2 years! Severe marketing and technical design mistakes by the Adobe management, IMHO.
Pharo suffers similar problems: GUI is not tablet-ready. Compare to Android 4.0: Android has joined the 2.3 line for mobiles with tablet line and has invested much much brainpower in finding out, how apps can be designed, that they can comfortably be used on different resolutions, portrait as well as landscape. Well done IMHO, even suited for desktop apps.
Pharo also has too much polling code, is eating up batteries as well.
As long as Apple does not allow fullsized interpreters in Appstore, there is definitely no chance ever for Pharo to be brought onto tablet.
I see no chances for Pharo on ARM, Tablets, whatever ... never ever!
This increasing market with hundreds of millions hardware units is completely lost for Smalltalkers, once again.
Tablet apps will very soon even dominate the desktop market!
regards, Guido Stepken
Am 22.02.2012 09:39 schrieb "Christoph Wysseier" <c.wysseier@netstyle.ch :
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and
others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
Or did I misinterpret your intention?
Cheers,
Chris
-- Milan Mimica http://sparklet.sf.net
Pharo is an IDE. IDEs don't run on tablets.
I hope to prove you the inverse. Because with a small core without browser you can build what you want. Way before the iPad, tansel ervasas sent to me a small squeak image with a simulation for a device ordering pizza and it was with pop up keys like iPad. They built it in one week and they could have ship it on the device. Politics made sure that it had to be written in Smalltalk. But open your eyes. Pharo is much more than an ide. Stef
On 22 February 2012 10:06, Guido Stepken <gstepken@googlemail.com> wrote: Hi Christoph!
Jobs dropped FLASH for several important reasons:
1. Too much polling in there. Processor load was high, eating up batteries. 2. Flash games with "onMouseOver" can't run on tablets. 3. Event model was so oldfashioned, that Adobe decided to drop the VM.
FLASH was the most successful virtual machine ever, hundreds of thousands of applications, billions of users, dominating the whole market.
Dead within only 2 years! Severe marketing and technical design mistakes by the Adobe management, IMHO.
Pharo suffers similar problems: GUI is not tablet-ready. Compare to Android 4.0: Android has joined the 2.3 line for mobiles with tablet line and has invested much much brainpower in finding out, how apps can be designed, that they can comfortably be used on different resolutions, portrait as well as landscape. Well done IMHO, even suited for desktop apps.
Pharo also has too much polling code, is eating up batteries as well.
As long as Apple does not allow fullsized interpreters in Appstore, there is definitely no chance ever for Pharo to be brought onto tablet.
I see no chances for Pharo on ARM, Tablets, whatever ... never ever!
This increasing market with hundreds of millions hardware units is completely lost for Smalltalkers, once again.
Tablet apps will very soon even dominate the desktop market!
regards, Guido Stepken Am 22.02.2012 09:39 schrieb "Christoph Wysseier" <c.wysseier@netstyle.ch>:
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse: I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
Or did I misinterpret your intention?
Cheers,
Chris
-- Milan Mimica http://sparklet.sf.net
On 22 February 2012 21:44, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Pharo is an IDE. IDEs don't run on tablets.
But open your eyes. Pharo is much more than an ide.
Exactly. And Squeak is even more than Pharo, but more is not better. I think we should focus and there is still too many opinions of what Pharo should be. Some try to pull in OpenGL interface, some would like to improve the headless mode, some use it as a web platform. Most efforts will go to waste. Pharo cannot possibly be that much. -- Milan Mimica http://sparklet.sf.net
On Feb 22, 2012, at 10:03 PM, Milan Mimica wrote:
On 22 February 2012 21:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Pharo is an IDE. IDEs don't run on tablets.
But open your eyes. Pharo is much more than an ide.
Exactly. And Squeak is even more than Pharo, but more is not better. I think we should focus and there is still too many opinions of what Pharo should be. Some try to pull in OpenGL interface, some would like to improve the headless mode, some use it as a web platform. Most efforts will go to waste. Pharo cannot possibly be that much.
well take what you believe is important for you and help us. For Moose and others openGL is important not to die, for coral and robot programming and server headless mode is important, for web servers are important. Now⦠why an XOR? Because we DID improve headless, we DID IMPROVE servers (ZINC) we DID improve UI. Now Zinc did not felt down from the sky, sven spent time because he needed and give it to YOU so ⦠now if you do not have the time to help this is ok (not even reading a bug tracker entry means that you are really busy but not enough since you still send mails), but look at what we DID!!! Stef
On 23 February 2012 07:58, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
well take what you believe is important for you and help us.
I will. Question: do you expect Pharo to fork into more specialized branches? I would like if that happened. -- Milan Mimica http://sparklet.sf.net
Why not.. How many branches does ubuntu have. I am not talking of whole of linux. But all of them will feed from the base and perhaps specialize in ways reqd. On Feb 23, 2012, at 10:50 PM, Milan Mimica <milan.mimica@gmail.com> wrote:
On 23 February 2012 07:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
well take what you believe is important for you and help us.
I will. Question: do you expect Pharo to fork into more specialized branches? I would like if that happened.
-- Milan Mimica http://sparklet.sf.net
I think better idea is to have easy to find one-click installations for different branches, like one ConfigurationOf for desktop programing, another for web programing, next one for ... Those installations must be bullet-proof tested to work for each Pharo version and tests can be done automatically with Jenkins CI server. One click install directly from Word submenu? Best regards Janko S, Krishsmalltalk piše:
Why not..
How many branches does ubuntu have. I am not talking of whole of linux. But all of them will feed from the base and perhaps specialize in ways reqd.
On Feb 23, 2012, at 10:50 PM, Milan Mimica <milan.mimica@gmail.com <mailto:milan.mimica@gmail.com>> wrote:
On 23 February 2012 07:58, Stéphane Ducasse <<mailto:stephane.ducasse@inria.fr>stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
well take what you believe is important for you and help us.
I will. Question: do you expect Pharo to fork into more specialized branches? I would like if that happened.
-- Milan Mimica <http://sparklet.sf.net>http://sparklet.sf.net
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On Feb 23, 2012, at 6:20 PM, Milan Mimica wrote:
On 23 February 2012 07:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
well take what you believe is important for you and help us.
I will. Question: do you expect Pharo to fork into more specialized branches? I would like if that happened.
I do not understand your question but did you read my answer. Did you SEE what we did in all these directions? Does it mean forking? NO it mens improving the infrastructure. Now guys I will stop because I have to work. You can read the Pharo vision and you will see. Now the message is focus on your future and share. Look at Sven. Stef
S, Milan Mimica piše:
> Pharo is an IDE. IDEs don't run on tablets.
But open your eyes. Pharo is much more than an ide.
Exactly. And Squeak is even more than Pharo, but more is not better. I think we should focus and there is still too many opinions of what Pharo should be. Some try to pull in OpenGL interface, some would like to improve the headless mode, some use it as a web platform. Most efforts will go to waste. Pharo cannot possibly be that much.
Agree, let we rather focus on few areas, specially in forthcoming Pharo Consortium. Is the goal of Pharo Vision document also to determine on which areas to focus? Fokus short-term and long term, and on which areas to just experiment for now ? Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On Feb 23, 2012, at 11:12 AM, Janko Mivšek wrote:
S, Milan Mimica piše:
Pharo is an IDE. IDEs don't run on tablets.
But open your eyes. Pharo is much more than an ide.
Exactly. And Squeak is even more than Pharo, but more is not better. I think we should focus and there is still too many opinions of what Pharo should be. Some try to pull in OpenGL interface, some would like to improve the headless mode, some use it as a web platform. Most efforts will go to waste. Pharo cannot possibly be that much.
Agree, let we rather focus on few areas, specially in forthcoming Pharo Consortium.
Is the goal of Pharo Vision document also to determine on which areas to focus?
It was more what we are working on and should finish. But the key underlying message: is focus on infrastructure - robust error handler - anonucnements - event hnalding - basic ui cleaning - cleaning cleaning cleaning to enable others to do something for their future.
Fokus short-term and long term, and on which areas to just experiment for now ?
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
my 2c. Pharo is not an IDE. It is a platform. About whether we should focus on Desktop or Web. My answer: both. Web main purpose was (and i think it will stay like that in a future) to deliver a content to user(s). A desktop is different: it is to provide a working place. There's a third niche, which is developing in recent years: small/embedded devices. No UI, no "browser" you can rely on, just a bare hardware. And Pharo also having something to propose in this direction. These directions is cross-pollinating. We want small, modular core? Ok. perfect match for embedded devices. We want a good FFI? Again, perfect match for OpenGL users. We want non-blocking, scalable I/O? perfect match for Web users. Now it doesn't means that non-blocking I/O is useful only for Web. I think if you take any direction, you will find that it quite useful there as well.
Hi Guido Am 22.02.12 10:06, schrieb Guido Stepken:
Tablet apps will very soon even dominate the desktop market!
I agree!
This increasing market with hundreds of millions hardware units is completely lost for Smalltalkers, once again.
I disagree! ;) It might be lost for standalone applications, right. But this is true for a lot of other technologies too, like the mentioned Adobe Flash, which also shows the difficulties of such a strategy. But, IMHO, the door to this market for Smalltalkers is wide open as long as you insist to use web-technologies (HTML5, AJAX, SVG et. al.) where Pharo and frameworks like Seaside or Aida/Web offer you a wide range of possibilities to develop platform-independent, innovative applications. Also Adobe justified their decision to drop Flash with the evalution of the future of these technologies. I am convinced that the future of such ($$$) business or community applications will be the browser. Just my 5 cents and may of course be completely wrong. Cheers, Chris
3. Event model was so oldfashioned, that Adobe decided to drop the VM.
Adobe would probably _like_ to drop the VM but that's unlikely...ever. They stopped the dual development approach: They have a VM for the hardware, and stopped trying to provide a VM for every BROWSER on every piece of hardware. Sensible. Or are you referring to the AVM -> AVM2 upgrade?
S, Christoph Wysseier piše:
Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. Including for mobile apps. Making a web app and package it as a standalone mobile app is much easier than making any decently looking GUI app with Pharo. Adding only multitouch is not enough, entire look&feel is what counts. And I don't see a change to better in near future on GUI field. It is better to concentrate improving Look&Feel (User Experience) of development tools and overal stability of Pharo including fundamental redesign of internals, those which cause instabilities. To prepare Pharo for server based deployments and for web services of different kinds, from web apps to REST API services. And a work the Gemstone/VMware guys are doing adding Smalltalk to Cloud Foudry [1] is what we should support as much as possible, this is the future. [1] Adding Smalltalk to Cloud Foundry http://programminggems.wordpress.com/2012/02/17/adding-smalltalk-to-cloud-fo... Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Le 22/02/2012 10:34, Janko Mivšek a écrit :
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. Including for mobile apps. Making a web app and package it as a standalone mobile app is much easier than making any decently looking GUI app with Pharo. Adding only multitouch is not enough, entire look&feel is what counts.
Sometime I wonder if writting application like DrGeo could be reasonnably doeable with html5? Ideally I would like to write Smalltalk code transated to the host language plateform. Whatever, html5 are really desktop application downloaded at runtime. We are still moving in circle since 40 years. -- Dr. Geo -- http://www.drgeo.eu
On 2/22/12, Hilaire Fernandes <hilaire.fernandes@edu.ge.ch> wrote:
Le 22/02/2012 10:34, Janko Mivšek a écrit :
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. Including for mobile apps. Making a web app and package it as a standalone mobile app is much easier than making any decently looking GUI app with Pharo. Adding only multitouch is not enough, entire look&feel is what counts.
Sometime I wonder if writting application like DrGeo could be reasonnably doeable with html5? Ideally I would like to write Smalltalk code transated to the host language plateform.
It would be worth giving it a try with a simple exercise... with Amber Smalltalk http://amber-lang.net/ and Morphic.js http://astares.blogspot.com/2011/03/morphic-in-javascript.html What is implemented so far http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.txt No idea if that offers enough for Dr. Geo....
Whatever, html5 are really desktop application downloaded at runtime. Yes there is now the option of 'one web page applications'.
This is done when going for an Amber solution actually. There is some discussion on Morphic on the Amber Smalltalk Google group; in short - you may add any JavaScript library to Amber. - you may call any JavaScript code just by entering it between < > (JavaScript code as 'primitive calls') - there are simple mapping rules so that you can call an existing JavaScript API with Smalltalk expressions. The new HTML5 <canvas> tag seems to offer a lot of possibilities. http://www.canvasdemos.com/ No idea however how it compares in terms of performance with a direct solution in Pharo.
are still moving in circle since 40 years. In which sense do you mean this?
The web browser is actually an universal client these days. Please note that Amber is still quite early in development --- version 0.9.1 And you have to shift gears mentally to get used to the file based approach (github). But actually it still feels like Smalltalk. For doing some experiments and proof of concept Amber is good enough. In case something does not work in Amber you can just do it in JavaScript. Smalltalk is no longer a closed world but running on top of a JavaScript engine where many external libraries are available. I think this is a very interesting development. --Hannes
-- Dr. Geo -- http://www.drgeo.eu
2012/2/22 Hilaire Fernandes <hilaire.fernandes@edu.ge.ch>
Le 22/02/2012 10:34, Janko Mivšek a écrit :
Whatever, html5 are really desktop application downloaded at runtime. We are still moving in circle since 40 years.
Full, full agree!
Dear Hilaire Am 22.02.12 10:38, schrieb Hilaire Fernandes:
Sometime I wonder if writting application like DrGeo could be reasonnably doeable with html5?
Without knowing your feature set in detail, but have a look for instance at the following SVG editor: -> http://code.google.com/p/svg-edit/ Although this does not nearly cover the features of your software, it shows amazingly what can be done with the HTML5 and SVG.
Whatever, html5 are really desktop application downloaded at runtime. We are still moving in circle since 40 years.
In some way you are right, some sort of things are being reinvented for new underlying technologies over and over again. Nevertheless, IMHO the development also exposed several sustainable advantages. As Hannes mentioned, the browser became a universal client for any applications, reducing the need to adapt applications for different operating system or other basic technologies. As far as I understand for instance Googles vision, it should even become the runtime environment of the user interface of the operating system. Besides, and this is especially true for mobile devices, using a client-server architecture the computation power and data storage shifts more and more to the server/cloud instead of the desktop. This is a large advantage for developers and system engineers for maintenance and operation especially when deploying a new version of a software as there is no software installed on the client directly. Cheers, Chris
Am 22.02.2012 11:45 schrieb "Christoph Wysseier" <c.wysseier@netstyle.ch>:
Dear Hilaire
Am 22.02.12 10:38, schrieb Hilaire Fernandes:
Sometime I wonder if writting application like DrGeo could be reasonnably doeable with html5?
Without knowing your feature set in detail, but have a look for instance
at the following SVG editor:
-> http://code.google.com/p/svg-edit/ Although this does not nearly cover the features of your software, it shows amazingly what can be done with the HTML5 and SVG.
Works fine on Nexus with Chrome Beta. :-) Perfect Cloud app and faaaast!!!! :-) OpenGL 2D canvas hardware support! Guido Stepken
Am 22.02.12 10:34, schrieb Janko Mivšek:
It is better to concentrate improving Look&Feel (User Experience) of development tools and overal stability of Pharo including fundamental redesign of internals, those which cause instabilities. To prepare Pharo for server based deployments and for web services of different kinds, from web apps to REST API services. And a work the Gemstone/VMware guys are doing adding Smalltalk to Cloud Foudry [1] is what we should support as much as possible, this is the future.
Just 100% my opinion too! But, to not shock the devs on this list, Pharo may offer much more than just an IDE with a headless operation on the server. Innovation on the server part is as important as using modern web-technologies for the user interface. Cheers, Chris
Am 22.02.2012 um 10:34 schrieb Janko Mivšek:
S, Christoph Wysseier piše:
Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. [stuff deleted]
I like Smalltalk the language for its orthogonality and power. If I hear a statement like "we should go <enter hype term here> because its the future!" I have the feeling that somebody wants some followers on his or her main area of interest. Web technologies bring some advantages in the software life cycle, mainly distribution. But they put additional burden in the GUI development because it's more complicated than traditional GUI's. Thus, you'll need a bigger user base for your application to make it worth the additional efforts in development. Additionally there are some areas where web GUI didn't catch up with traditional GUI's at all. Regards Andreas
"Web technologies bring some advantages in the software life cycle, mainly distribution." Very succint. Not to deprecate a great technical development over the years, that makes even complete non techies capable of using the computer, which desktop GUI does not enable easily, applet was a compromise but did not scale well. But its an overkill fed into enterprise mainstream, which actually do have IT depts and ability to manage an automated client update/ installations. Server side of the web tech is great and should be the mainstay for a re-imagined desktop client and bring back iPad like UI experience to the desktop, tablet et als. On Thu, Feb 23, 2012 at 3:30 AM, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:
Am 22.02.2012 um 10:34 schrieb Janko Mivšek:
S, Christoph Wysseier piše:
Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. [stuff deleted]
I like Smalltalk the language for its orthogonality and power. If I hear a statement like "we should go <enter hype term here> because its the future!" I have the feeling that somebody wants some followers on his or her main area of interest.
Web technologies bring some advantages in the software life cycle, mainly distribution. But they put additional burden in the GUI development because it's more complicated than traditional GUI's. Thus, you'll need a bigger user base for your application to make it worth the additional efforts in development. Additionally there are some areas where web GUI didn't catch up with traditional GUI's at all.
Regards Andreas
Dear Andreas Am 22.02.12 23:00, schrieb Andreas Wacknitz:
Am 22.02.2012 um 10:34 schrieb Janko Mivšek:
S, Christoph Wysseier piše:
Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. [stuff deleted]
I like Smalltalk the language for its orthogonality and power. If I hear a statement like "we should go<enter hype term here> because its the future!" I have the feeling that somebody wants some followers on his or her main area of interest.
Although I do not believe Web technolgies to be just a hype, it was not my intention at all to convince everyone working with Pharo to use it from now on for web applications only. There are of course several stakeholders with different business or community ideas. Nevertheless, as we and others are using Pharo as an IDE to develop web applications we need to be able to count on the support of the board and community that the further development considers our business model which does not lock out other ideas at all.
Web technologies bring some advantages in the software life cycle, mainly distribution. But they put additional burden in the GUI development because it's more complicated than traditional GUI's. Thus, you'll need a bigger user base for your application to make it worth the additional efforts in development. Additionally there are some areas where web GUI didn't catch up with traditional GUI's at all.
As already Esteban mentioned it depends on the use case. The applications we develop are far easier to realise using web-based GUIs. Besides the development and deployment, the resulting applications offer a lot of additional benefits in contrast to standalone software. But you are right, this of course does not apply to every requirements at all. Regards, Chris
Christoph, Am 23.02.2012 um 09:31 schrieb Christoph Wysseier:
Dear Andreas
Am 22.02.12 23:00, schrieb Andreas Wacknitz:
Am 22.02.2012 um 10:34 schrieb Janko Mivšek:
S, Christoph Wysseier piše:
Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time. Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
I agree completely that web based techologies are where we should go because we have advantage here with Smalltalk while for any kind of GUI we are off. [stuff deleted]
I like Smalltalk the language for its orthogonality and power. If I hear a statement like "we should go<enter hype term here> because its the future!" I have the feeling that somebody wants some followers on his or her main area of interest.
Although I do not believe Web technolgies to be just a hype, it was not my intention at all to convince everyone working with Pharo to use it from now on for web applications only. There are of course several stakeholders with different business or community ideas. Nevertheless, as we and others are using Pharo as an IDE to develop web applications we need to be able to count on the support of the board and community that the further development considers our business model which does not lock out other ideas at all.
My message was not a reaction to your mail but to Janko's. I want Smalltalk (and especially Pharo) as an all purpose system. In my opinion it's a mistake to focus on a certain area like web technologies. And I guess as long as Pinesoft is doing well in business with traditional GUI's and INRIA is interested in research in dynamic languages (and not dynamic web languages) I don't have to fear that Pharo will go in that direction :-) Regards, Andreas
2012/2/22 Christoph Wysseier <c.wysseier@netstyle.ch>
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others
works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time.
Or maybe web application disappear over time. Most device providers creates own app stores which includes native application for devices (not web applications). And specialised devices market always grow. All customers want see there client frontend applications at each market. I think standalone computers will become less popular each year. And so classic web applications too.
Hi, El 22/02/2012, a las 8:07a.m., Denis Kudriashov escribió:
2012/2/22 Christoph Wysseier <c.wysseier@netstyle.ch> Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time.
I don't see this happening anytime soon either. I think two years ago this was the most extended concept about the future of computers (and I was a bit disappointed, tbh), but that changed a lot with tablet market growing: most tablet applications are standalone applications, old fashioned desktop apps (and even some are old fashion client-server apps). This is not decreasing, but the opposite. Even more, I observed that, while big companies, in effect, are moving to web platform and cloud. Small companies prefer desktop applications. As I said in web panel at ESUG: I already saw this happening. Time to time development moves onto one direction (all in the desktop, all in the server) and people seems to think one of the sides will prevail... I think real future is (and always has been) somewhere in the middle... taking case to case to decide, there is no one unique answer. best, Esteban
Or maybe web application disappear over time. Most device providers creates own app stores which includes native application for devices (not web applications). And specialised devices market always grow. All customers want see there client frontend applications at each market.
I think standalone computers will become less popular each year. And so classic web applications too.
Dear Esteban Am 22.02.12 13:11, schrieb Esteban Lorenzano:
Hi,
2012/2/22 Christoph Wysseier <c.wysseier@netstyle.ch <mailto:c.wysseier@netstyle.ch>> Am 22.02.12 08:32, schrieb Stéphane Ducasse: I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time.
I don't see this happening anytime soon either. I think two years ago this was the most extended concept about the future of computers (and I was a bit disappointed, tbh), but that changed a lot with tablet market growing: most tablet applications are standalone applications, old fashioned desktop apps (and even some are old fashion client-server apps). This is not decreasing, but the opposite. Even more, I observed that, while big companies, in effect, are moving to web platform and cloud. Small companies prefer desktop applications.
As I said in web panel at ESUG: I already saw this happening. Time to time development moves onto one direction (all in the desktop, all in the server) and people seems to think one of the sides will prevail... I think real future is (and always has been) somewhere in the middle... taking case to case to decide, there is no one unique answer.
You are right, Esteban, there is no unique answer to every use case. As always in computer science one has to find the optimal solution. My statement was not carefully worded enough, it was more intended to be my observation of the current trends for business applications we develop. Those are all for small Swiss companies and they are very happy to not maintain a desktop software distribution architecture. But I am aware of the fact that this observation might not fit to the whole industry. At app stores I look quite differently. IMHO app stores with standalone applications are a temporary fashion (although the current development is the opposite) because it gave the opportunity to earn a lot of money for large industry companies with a lock-in for app developers. My prediction is that sometimes the pendulum will swing back as soon as the technology really allows to create apps with the same user experience and simplicity using web-technologies. In that scenario, you will not have to pay x% to the app store operator which will be also a reason avoiding such stores in the future. Cheers, Chris
On Feb 22, 2012, at 9:38 AM, Christoph Wysseier wrote:
Dear Stef
Am 22.02.12 08:32, schrieb Stéphane Ducasse:
I'm convinced that having support for multitouch event/ genie and others works (for iPad = $$$$) is important.
Without pretending to know the future, IMHO standalone apps for tablets and mobile will disappear over time.
we will see :) I do not have a crystal ball either. Now I can tell you that I'm in contact with a serious company and we are about to release a product on iPad and iPhone in C++ and they do not want to write it in web-based.
Out of my perspective it would be far more important to move in the direction of web-based technologies also in this area. Looking at the success stories of Pharo and our own strategy I do not see the advantages of having multi-touch support for the development of such applications.
Now when genie was added to squeak is was a hack because the event loop was not pluggable. Now if people (not me) want to use pharo to build strange interactive devices (again they have to hack to death the system), if hilaire wants to have DrGeo on iPad, same for Fernando with alternate desktop or android desktop. So if we want to give a chance to people to build their own future then we should get a nice infrastructure.
Or did I misinterpret your intention?
Cheers,
Chris
2012/2/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hi janko
More polishing and boring bug hunting tasks therefore and just a bit less fundamental rewritings like compiler etc.
Did you ever look at one bug entry? You see the bug entry does not magically empty itself. There are people like me and marcus and a couple of others that are looking at reports, producing fixes...
Hi Stef: This may or may not be the proper site to put my feelings, but still, they are with the intention of help and construct. When Pharo not existed, and almost all of us were in Squeak (I'm still there, only watching now) I remember to be worried all the time by have 3000 or more unread mails, lot of threads and talks that I couldn't follow. And the other problem was all the time all things changing, then we had in Smalltalk the sort of problems that we criticized in other platforms, the software written today will not run tomorrow in the new version (I remember for example Squeak modules, around 2003). Now It's happening to me that I'm having more than 6000 unread mails in the Pharo main list (and more than 700 in pharo users) and the Pharo ecosystem grew up at a limit very hard to follow to me. I tried to help in different ways, solving bugs, building somethings as xmlrpc (with the invaluable help of ESUG) but happens that (having other 2 jobs to survive) is not easy to find the free time to help, and this is worst when the ecosystem grew as is happening with Pharo (lot of different ideas, frameworks, ways to do the things) I'm not crying, only describ my reality, I would love to be some sort of researcher working all time in cool stuff as Pharo and friends, but unfortunately is not my reality and in this context, find free time to help is a problem, and a previous worst problem is find free time to follow the community, understand the context and be up to date with all the new things and how they change and affect the already written software. Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4. Just my feelings. Cheers.
Germán, On 22 Feb 2012, at 13:28, Germán Arduino wrote:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
I think I said it before (but I can't remember it must be a long time ago): I am more than willing to help you port it. I am not a fan of XMLRPC, but it is an existing standard that has its place. Furthermore, it was designed to be very simple, so it would be a shame to let it rot away. Sven
I am willing to contribute to XMLRPC.. Hopefully will integrate a full fledged interface between Pharo and Groovy and have it run load and atleast a complete JDBC optimized interface and a pure XMLRpc bridge to the outer world.. So will have inputs and ability to ensure that it stays in shape ahead. I do not promise porting to Zinc or the likes immediately but may eventually if it makes a greater performance sense.. On Wed, Feb 22, 2012 at 6:23 PM, Sven Van Caekenberghe <sven@beta9.be>wrote:
Germán,
On 22 Feb 2012, at 13:28, Germán Arduino wrote:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
I think I said it before (but I can't remember it must be a long time ago): I am more than willing to help you port it. I am not a fan of XMLRPC, but it is an existing standard that has its place. Furthermore, it was designed to be very simple, so it would be a shame to let it rot away.
Sven
On 22 Feb 2012, at 17:52, S Krish wrote:
I am willing to contribute to XMLRPC.. Hopefully will integrate a full fledged interface between Pharo and Groovy and have it run load and atleast a complete JDBC optimized interface and a pure XMLRpc bridge to the outer world..
Great !
So will have inputs and ability to ensure that it stays in shape ahead. I do not promise porting to Zinc or the likes immediately but may eventually if it makes a greater performance sense..
It is dead simple to port XMLRPC to Zinc HTTP Components, client side is just a POST, server side is nothing more than accepting a POST on an endpoint. It would be a huge mistake to try to stay compatible with old stuff. Zinc has been a standard part of Pharo since 1.3. Sven
Sure will take it up .. and post back if I need anything. On Wed, Feb 22, 2012 at 11:22 PM, Sven Van Caekenberghe <sven@beta9.be>wrote:
On 22 Feb 2012, at 17:52, S Krish wrote:
I am willing to contribute to XMLRPC.. Hopefully will integrate a full fledged interface between Pharo and Groovy and have it run load and atleast a complete JDBC optimized interface and a pure XMLRpc bridge to the outer world..
Great !
So will have inputs and ability to ensure that it stays in shape ahead. I do not promise porting to Zinc or the likes immediately but may eventually if it makes a greater performance sense..
It is dead simple to port XMLRPC to Zinc HTTP Components, client side is just a POST, server side is nothing more than accepting a POST on an endpoint. It would be a huge mistake to try to stay compatible with old stuff. Zinc has been a standard part of Pharo since 1.3.
Sven
Thanks! I will try to start as soon as I can. Germán. 2012/2/22 S Krish <krishnamachari.sudhakar@gmail.com>
I am willing to contribute to XMLRPC.. Hopefully will integrate a full fledged interface between Pharo and Groovy and have it run load and atleast a complete JDBC optimized interface and a pure XMLRpc bridge to the outer world..
So will have inputs and ability to ensure that it stays in shape ahead. I do not promise porting to Zinc or the likes immediately but may eventually if it makes a greater performance sense..
On Wed, Feb 22, 2012 at 6:23 PM, Sven Van Caekenberghe <sven@beta9.be>wrote:
Germán,
On 22 Feb 2012, at 13:28, Germán Arduino wrote:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
I think I said it before (but I can't remember it must be a long time ago): I am more than willing to help you port it. I am not a fan of XMLRPC, but it is an existing standard that has its place. Furthermore, it was designed to be very simple, so it would be a shame to let it rot away.
Sven
HI Sven, yes I think the same, as soon as I can find a bit of time will port it and will ask any doubt. Thanks for the help offer! 2012/2/22 Sven Van Caekenberghe <sven@beta9.be>
Germán,
On 22 Feb 2012, at 13:28, Germán Arduino wrote:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
I think I said it before (but I can't remember it must be a long time ago): I am more than willing to help you port it. I am not a fan of XMLRPC, but it is an existing standard that has its place. Furthermore, it was designed to be very simple, so it would be a shame to let it rot away.
Sven
-- ============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================
Am 22.02.2012 um 13:28 schrieb Germán Arduino:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
What are your building blocks except http and xml? If you were working on 1.1.1 then xml parser moved quite a bit and zinc appeared on the scene. The changes to adopt xml parser should be minimal. Zinc provides a facade that mimicks backward compatibility. So you could have an easy start. But to be honest the situation is soooo much better with having zinc that you might save some time in development if you use zinc straight away. And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is stable since months and the change rate in zinc is also dropping. So you might expect them to be available until...let's say...3 months from now. :) Ok, just kidding, I think the will stay similar for quite some time. Norbert
2012/2/22 Norbert Hartl <norbert@hartl.name>
Am 22.02.2012 um 13:28 schrieb Germán Arduino:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
What are your building blocks except http and xml? If you were working on 1.1.1 then xml parser moved quite a bit and zinc appeared on the scene. The changes to adopt xml parser should be minimal. Zinc provides a facade that mimicks backward compatibility. So you could have an easy start. But to be honest the situation is soooo much better with having zinc that you might save some time in development if you use zinc straight away. And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is stable since months and the change rate in zinc is also dropping. So you might expect them to be available until...let's say...3 months from now. :) Ok, just kidding, I think the will stay similar for quite some time.
Norbert
Hi Norbert! Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast. Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ? Germán.
Am 22.02.2012 um 21:41 schrieb Germán Arduino <garduino@gmail.com>:
2012/2/22 Norbert Hartl <norbert@hartl.name>
Am 22.02.2012 um 13:28 schrieb Germán Arduino:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
What are your building blocks except http and xml? If you were working on 1.1.1 then xml parser moved quite a bit and zinc appeared on the scene. The changes to adopt xml parser should be minimal. Zinc provides a facade that mimicks backward compatibility. So you could have an easy start. But to be honest the situation is soooo much better with having zinc that you might save some time in development if you use zinc straight away. And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is stable since months and the change rate in zinc is also dropping. So you might expect them to be available until...let's say...3 months from now. :) Ok, just kidding, I think the will stay similar for quite some time.
Norbert
Hi Norbert!
Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast.
Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ?
I don't think it makes a huge difference. As long as 1.4 is not to be released soon it would be better to port it to 1.3. This way people can use it. But honestly I think you develop it against zinc and xml parser. Zinc has been updated in 1.3 lately but I don't know if it is the newest stuff. Sven knows it. Norbert
2012/2/22 Norbert Hartl <norbert@hartl.name>
Hi Norbert!
Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast.
Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ?
I don't think it makes a huge difference. As long as 1.4 is not to be released soon it would be better to port it to 1.3. This way people can use it. But honestly I think you develop it against zinc and xml parser. Zinc has been updated in 1.3 lately but I don't know if it is the newest stuff. Sven knows it.
Norbert
Yes, I asked mainly already knowing that I'm slow with these stuff, because I have almost not free time. Germán. -- ============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================
Hi Norbert!
Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast.
Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ?
There should be not that much difference for XML and Zinc API between 1.3 and 1.4 (even if Zinc changes much more than XML. Now I code in 1.4 most of my time.
Germán.
Am 22.02.2012 um 22:06 schrieb Germán Arduino <garduino@gmail.com>:
2012/2/22 Stéphane Ducasse <stephane.ducasse@inria.fr>
Now I code in 1.4 most of my time.
Thanks, this is a response to me :)
Don't forget that Steph is the counter type of your potential audience. So don't follow him but do the opposite :) Norbert
hehe, well, I say in the sense that it's greatly possible that 1.4 is released BEFORE I can even write a single line of the new xmlrpc... :) 2012/2/22 Norbert Hartl <norbert@hartl.name>
Am 22.02.2012 um 22:06 schrieb Germán Arduino <garduino@gmail.com>:
2012/2/22 Stéphane Ducasse <stephane.ducasse@inria.fr>
Now I code in 1.4 most of my time.
Thanks, this is a response to me :)
Don't forget that Steph is the counter type of your potential audience. So don't follow him but do the opposite :)
Norbert
:) We got a team meeting around 1.4 release yesterday and we have to fix some points first :)
hehe, well, I say in the sense that it's greatly possible that 1.4 is released BEFORE I can even write a single line of the new xmlrpc... :)
Now I code in 1.4 most of my time.
Thanks, this is a response to me :)
Don't forget that Steph is the counter type of your potential audience. So don't follow him but do the opposite :)
Norbert
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 22 Feb 2012, at 22:04, Stéphane Ducasse wrote:
Hi Norbert!
Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast.
Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ?
There should be not that much difference for XML and Zinc API between 1.3 and 1.4 (even if Zinc changes much more than XML.
Now I code in 1.4 most of my time.
Germán.
Normally you would write XMLRPC against Zinc HTTP Components and XML Support, both are working fine on 1.3 and 1.4. Pharo 1.3 is released and in that sense more stable (as in predictable and not changing as much), but 1.4 has much more of the latest features/fixes and is generally more fun (but you'll be living on the edge). Here is an XMLRPC call without the infrastructure of generating/parsing the proper XML: | call | call := '<?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall>'. ZnClient new url: 'http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx'; entity: (ZnEntity with: call type: ZnMimeType applicationXml); post. Regards, Sven
Thanks Sven, you inject me the desire of put hands on the stuff asap, but unfortunately, need to end other things first (business related things I mean). Thanks really! 2012/2/22 Sven Van Caekenberghe <sven@beta9.be>
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 22 Feb 2012, at 22:04, Stéphane Ducasse wrote:
Hi Norbert!
Yes, I know that the situation is better with Zinc (I checked the code and really look nice and simple to understand). I only mentioned XMLRPC as a mere example of how the things become unusable so fast.
Talking about this what you guys consider best, migrate XMLRPC to 1.3 or directly to 1.4 ?
There should be not that much difference for XML and Zinc API between 1.3 and 1.4 (even if Zinc changes much more than XML.
Now I code in 1.4 most of my time.
Germán.
Normally you would write XMLRPC against Zinc HTTP Components and XML Support, both are working fine on 1.3 and 1.4. Pharo 1.3 is released and in that sense more stable (as in predictable and not changing as much), but 1.4 has much more of the latest features/fixes and is generally more fun (but you'll be living on the edge).
Here is an XMLRPC call without the infrastructure of generating/parsing the proper XML:
| call | call := '<?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall>'. ZnClient new url: 'http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx'; entity: (ZnEntity with: call type: ZnMimeType applicationXml); post.
Regards,
Sven
-- ============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================
On Feb 22, 2012, at 1:58 PM, Norbert Hartl wrote:
Am 22.02.2012 um 13:28 schrieb Germán Arduino:
Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4.
What are your building blocks except http and xml? If you were working on 1.1.1 then xml parser moved quite a bit and zinc appeared on the scene. The changes to adopt xml parser should be minimal. Zinc provides a facade that mimicks backward compatibility. So you could have an easy start. But to be honest the situation is soooo much better with having zinc that you might save some time in development if you use zinc straight away. And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is stable since months and the change rate in zinc is also dropping. So you might expect them to be available until...let's say...3 months from now. :) Ok, just kidding, I think the will stay similar for quite some time.
Exactly. Doru got **all** the moose tools in 1.4 and some of them like glamour rely a lot on UI changes. I doubt that xmlrpc got any impacted on Morphic change. We do not change XML (but the XML maintainers did) and Zinc is just much much much better than the old system so it should be not difficult to adapt especially if you ask. Stef
Dear Janko Am 21.02.12 13:07, schrieb Janko Mivšek:
Hi Chris,
Thank you very much for your experience report and I think I'm not alone to like to hear from your more about what are your wishes as a manager from the Pharo in the future. Because you are an "enterprise" (in a positive meaning of that word) Pharo user.
Thank you for your warm welcome! I hope to not boring the list with my business gibberish. I promise to keep quiet again very soon. ;)
Maybe let me start asking you an opinion of what I'd like to see from Pharo as a priority:
- more stability, - better user experience (UX), - better version control and packaging tools - better integration of tools - tabbed browsing, back button etc
Although stability and performance are important priorities, as far as we are concerned stability is not a large issue. With 10 years of experience operating hundreds of such applications we were able to build a framework which operates such web applications reliable. And Pharo even improved this situation a lot. We would only wish some small improvement like error handling on startup and seldomly Pharo image are freezing, but this is hard to debug. Our priority would be definitely the improvement of the IDE and source code management. Working with Smalltalk is already fun and offers a very efficient way of developing sophisticated solutions, if the IDE would further simplify the process of developing step-by-step, the work with Pharo would make more and more fun. But, working on the UX is far not the same as working on new feature or hunting bugs. It needs a clear vision for everyone working with it and changes need to be deployed carefully. This would be one of our seldom criticism. A few changes in the handling of the IDE were surprising and appeared to be without any concept (which also means that we just did not understand the idea behind). IMHO, such improvements would need a careful planning and communication with the final users. The integration of tools is not that important. We just use external software such as PostgresQL, ImageMagick, Apache FOP, etc. which can be connected using several, pretty stable interfaces.
More polishing and boring bug hunting tasks therefore and just a bit less fundamental rewritings like compiler etc. Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the above priorities are much more important.
I agree with Stef. Of course the above priorities are much more important for our own businesses. Nevertheless, a lively community and an innovative strategy would not exist if the Pharo board would concentrate on these priorities only. Pharo should allow to develop innovative other applications and new development concepts too. And, it is a fact that this intelligent community is driven by some academic users which is exactly why we believe it to become better and better. Regards, Chris
Hi Chris, On 21 Feb 2012, at 12:12, wysseier wrote:
It is not up to me whether our CMSBOX is an important project in a general context. But to answer your question: almost 500 customers in Switzerland are using this Pharo-based application until now and for them, this application and the underlying very stable technology with ongoing development IS important. Besides, we at netstyle.ch created several business critical web-based applications, from automatic inventory management to a large CRM for a Swiss insurance broker. Although you probably never heard of these applications I guess we are nevertheless an important component of the Pharo eco system and we use it because we believe it to be the right way of the ongoing development.
Although there is always room for improvement, the migration to Pharo was and is an important step within our company strategy. On this basis, we built a company from scratch with more than 10 employees whereof five software engineers are doing nothing else than working with the Pharo IDE. It is due to the ongoing development of a small community that our personal "success" became possible. Could not be more thankful for that! Keep the work going!
To now improve whatever needs to improved in your opinion, one should not issue orders to or offend the community but to collaborate constructively on suggestions. Honestly, this was not our strength within the past months too, but we are willing to support this lively community as much as we can in the future although we are not Wikipedia or similar. I am convinced that a constructive and appreciative collaboration is the only way to improve Pharo so please consider my words when writing your next message.
Cheers,
Chris Wysseier Founder and CEO of netstyle.ch and cmsbox
P.S: Also wanted to say hi to everybody as I am new on the list. Be aware that I am not an *experienced* software engineer (let's say "anymore" ;) ) and therefore will not be able to discuss on technical strategies or tasks. But I would like to know what is going on and to show support and presence to all of you.
Thanks for sharing this information! This is good to hear. We hope to hear more from you and the netstyle Smaltalkers in the future. Sven
Thanks a lot Christophe! I love your trust :) It puts such responsibility on us but we accept it and we will do our best to make sure you can deliver robust and cool applications. For your information, Pinesoft's CEO told me that they are full of Pharo projects - a great news. Stef
It is not up to me whether our CMSBOX is an important project in a general context. But to answer your question: almost 500 customers in Switzerland are using this Pharo-based application until now and for them, this application and the underlying very stable technology with ongoing development IS important. Besides, we at netstyle.ch created several business critical web-based applications, from automatic inventory management to a large CRM for a Swiss insurance broker. Although you probably never heard of these applications I guess we are nevertheless an important component of the Pharo eco system and we use it because we believe it to be the right way of the ongoing development.
Although there is always room for improvement, the migration to Pharo was and is an important step within our company strategy. On this basis, we built a company from scratch with more than 10 employees whereof five software engineers are doing nothing else than working with the Pharo IDE. It is due to the ongoing development of a small community that our personal "success" became possible. Could not be more thankful for that! Keep the work going!
To now improve whatever needs to improved in your opinion, one should not issue orders to or offend the community but to collaborate constructively on suggestions. Honestly, this was not our strength within the past months too, but we are willing to support this lively community as much as we can in the future although we are not Wikipedia or similar. I am convinced that a constructive and appreciative collaboration is the only way to improve Pharo so please consider my words when writing your next message.
Cheers,
Chris Wysseier Founder and CEO of netstyle.ch and cmsbox
P.S: Also wanted to say hi to everybody as I am new on the list. Be aware that I am not an *experienced* software engineer (let's say "anymore" ;) ) and therefore will not be able to discuss on technical strategies or tasks. But I would like to know what is going on and to show support and presence to all of you.
-- View this message in context: http://forum.world.st/Do-not-feed-the-trolls-tp4405636p4406708.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Dear Stef, Am 21.02.12 21:26, schrieb Stéphane Ducasse:
Thanks a lot Christophe! I love your trust :) It puts such responsibility on us but we accept it and we will do our best to make sure you can deliver robust and cool applications.
Trust is the best motivation... :) It was not my intention to put pressure to you or the community. I believe that Pharo improved our situation a lot in the last years and that the project is on the right track. For us the lively and very intelligent community that built and maintains a stable Open Source Smalltalk IDE for the development of (web-based) commercial application is the most important thing. If you listen to the wishes of commercial users and we appreciate and support your work then Pharo will become even more successful, attractive and fun. Cheers, Chris
Nice try, Dale, but this troll will apparently eat anything - even Wikipedia articles :-p -- Cheers, Peter.
Much simpler calling s.b. a troll than changing own behaviour!!! :-) You get old and unflexible, when you rather start to defend, refusing to see facts: "Its not me, who is responsible for the failing of the product in the market, i am working hard!!!!!" Always the same .... I hate it, this attitude. tnx 4 understanding, Guido Stepken Am 21.02.2012 02:29 schrieb "Peter Hugosson-Miller" <oldmanlink@gmail.com>:
Nice try, Dale, but this troll will apparently eat anything - even Wikipedia articles :-p
-- Cheers, Peter.
Guido, I'd rather focus on positive energy. Please understand that you're not helping, at all. I'm kindly asking you to stop, you're attitude is polluting this mailing list. Cheers, Nico On 21/02/12 02:40, Guido Stepken wrote:
Much simpler calling s.b. a troll than changing own behaviour!!! :-)
You get old and unflexible, when you rather start to defend, refusing to see facts:
"Its not me, who is responsible for the failing of the product in the market, i am working hard!!!!!"
Always the same .... I hate it, this attitude.
tnx 4 understanding,
Guido Stepken
Am 21.02.2012 02:29 schrieb "Peter Hugosson-Miller" <oldmanlink@gmail.com <mailto:oldmanlink@gmail.com>>:
Nice try, Dale, but this troll will apparently eat anything - even Wikipedia articles :-p
-- Cheers, Peter.
-- Nicolas Petton http://nicolas-petton.fr
I don't know if it's good idea but what about adding it to aidaDescriptor? e.g we would have: (descriopton textFieldOn: #someAspect) Presenter: StandardTextPresenter on: Accepter: StandardAccepter for: or the like In CLIM the presenter depends on the stream for output see clim specification http://bauhh.dyndns.org:8000/clim-spec/index.html There we may have a different presentatoin depending on the outputstream it looks like this (in pseudo Lisp defmethod present ((anEmployee emp) (view +text-view+)) presents an emp on a text-view we may also have defmethod present ((anEmploeyee emp) (view +overview-view+) and this may e.g have name, firstname etc. and it will have different kinds of accepters also. But that's just an consideration. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
participants (29)
-
Andreas Wacknitz -
Andreas Wacknitz
-
blake -
Camillo Bruni -
Christoph Wysseier -
Dale Henrichs -
Dave Mason -
Denis Kudriashov -
Esteban Lorenzano -
Friedrich Dominicus -
Germán Arduino -
Guido Stepken -
H. Hirzel -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
Jimmie Houchin -
Krishsmalltalk -
Milan Mimica -
Nicolas Petton -
Norbert Hartl -
Peter Hugosson-Miller -
S Krish
-
Schwab,Wilhelm K -
Stuart Herring -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tobias Pape -
wysseier