June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.2] #12024

by Pavel Krivanek

It will be better to modify the update 12024 directly. Reloading of the packages will not remove the obsolete classes. -- Pavel On Wed, Jun 30, 2010 at 8:00 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > In the image 12023 do: > > BreakPoint category: 'System-BreakPoints'. > BreakpointManager category: 'System-BreakPoints'. > MczInstaller category: 'System-Installers'. > SARInstaller category: 'System-Installers' > > ScriptLoader new addPackage: 'System-Installers'. > ScriptLoader new addPackage: 'System-BreakPoints'. > > Upload this new packages to the repository and add them to the next update. > > -- Pavel > > On Wed, Jun 30, 2010 at 7:55 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> do you have a fix? >> >> Stef >> >> On Jun 30, 2010, at 7:49 PM, Pavel Krivanek wrote: >> >>> Great! >>> >>> there are two issues: there's no new package System-BreakPoints (my >>> fault) and System-Installers. >>> >>> SystemNavigation default obsoleteClasses -> an >>> Array(AnObsoleteSARInstaller AnObsoleteBreakPoint >>> AnObsoleteBreakpointManager AnObsoleteMczInstaller) >>> >>> The empty system and method categories should be removed. >>> >>> -- Pavel >>> >>> On Wed, Jun 30, 2010 at 7:09 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Pavel can you have a look to see if everything is ok? >>>> >>>> 12024 >>>> ----- >>>> >>>> - Issue 2105: Â Packages remodularization >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

June 30, 2010

Re: [Pharo-project] [SPAM] [ANN 1.1] pre-built RC3 Core

by Mariano Martinez Peck

On Wed, Jun 30, 2010 at 4:08 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 30 Jun 2010, at 09:37, Marcus Denker wrote: > > > > > > https://gforge.inria.fr/frs/download.php/27218/PharoCore-1.1-11406-rc3.zip > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > What is the development plan and timing for 1.1 ? > > I understand that there is some kind of feature freeze for 1.1 with all new > stuff going into 1.2. > > How is beta testing in 1.1 supposed to happen ? > It is already available the RC2 since a couple of weeks: http://www.pharo-project.org/pharo-download there you will see Pharo 1.1 RC2. I will (very soon) create a PharoDev 1.1 RC3 based in this new core. > > I don't see many people reporting issues on the mailing list vs 1.1 > > My 1.1 (11400 rc2) image prints numbers on the transcript when doing > certain editing (selection ?) operations. > > Please, report it a new thread/issue. Cheers Mariano > Sven > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by Philippe Marschall

On 28.06.2010 23:18, GermÃ¡n Arduino wrote: > 2010/6/28 Philippe Marschall <philippe.marschall(a)netcetera.ch>: >> On 06/28/2010 12:25 AM, GermÃ¡n Arduino wrote: >>> As flickr, >> >> Besides REST and SOAP >> >>> blogger, >> >> Nope, not any more. >> >>> wordpress, >> >> ok >> >>> Joomla sites, >> >> ok >> >>> Google blog search, >> >> Couldn't find anything about it. Google is standardizing on GData and >> "AJAX". Even SOAP is being phased out. >> >>> Drupal sites, >> >> Moving away from XML-RPC like anybody else. >> >>> delicious, >> >> Couldn't find anything XML-RPC related, seems to use "REST". >> >>> zope, >> >> OK. >> >>> products as SAP, >> >> Still? I would have assumed they moved on. >> >>> to mention a few that >>> I have in mind now.... >>> >>> I means, not only web sites, also products and I think also that is a >>> compact protocol that could permit to implement an API to servers / >>> products easily. >> >> My impression is that people either moved from XML-RCP to SOAP or >> abandoned the idea and went to REST. I don't know anybody who considers >> it for new projects. >> > > Blogger and Google in general yes, are moving to GData but xml-rpc is > still suported. > > But I understand your point, you think that isn't worth to invest in > this protocol. It doesn't strike me as a forward looking investment. IMHO XML-RCP is something that will only get used less in the future, not more. The value you get from an XML-RCP implementation will become less and less as fewer services support it. But then again ESUG is free to spend their money on what they seem fit. If they disagree or decide the current use is big enough, I have no problem at all with this. Cheers Philippe

June 30, 2010

Re: [Pharo-project] [update 1.2] #12024

by Pavel Krivanek

In the image 12023 do: BreakPoint category: 'System-BreakPoints'. BreakpointManager category: 'System-BreakPoints'. MczInstaller category: 'System-Installers'. SARInstaller category: 'System-Installers' ScriptLoader new addPackage: 'System-Installers'. ScriptLoader new addPackage: 'System-BreakPoints'. Upload this new packages to the repository and add them to the next update. -- Pavel On Wed, Jun 30, 2010 at 7:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > do you have a fix? > > Stef > > On Jun 30, 2010, at 7:49 PM, Pavel Krivanek wrote: > >> Great! >> >> there are two issues: there's no new package System-BreakPoints (my >> fault) and System-Installers. >> >> SystemNavigation default obsoleteClasses -> an >> Array(AnObsoleteSARInstaller AnObsoleteBreakPoint >> AnObsoleteBreakpointManager AnObsoleteMczInstaller) >> >> The empty system and method categories should be removed. >> >> -- Pavel >> >> On Wed, Jun 30, 2010 at 7:09 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Pavel can you have a look to see if everything is ok? >>> >>> 12024 >>> ----- >>> >>> - Issue 2105: Â Packages remodularization >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

Re: [Pharo-project] [update 1.2] #12024

by StÃ©phane Ducasse

do you have a fix? Stef On Jun 30, 2010, at 7:49 PM, Pavel Krivanek wrote: > Great! > > there are two issues: there's no new package System-BreakPoints (my > fault) and System-Installers. > > SystemNavigation default obsoleteClasses -> an > Array(AnObsoleteSARInstaller AnObsoleteBreakPoint > AnObsoleteBreakpointManager AnObsoleteMczInstaller) > > The empty system and method categories should be removed. > > -- Pavel > > On Wed, Jun 30, 2010 at 7:09 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Pavel can you have a look to see if everything is ok? >> >> 12024 >> ----- >> >> - Issue 2105: Packages remodularization >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] [update 1.2] #12024

by Pavel Krivanek

Great! there are two issues: there's no new package System-BreakPoints (my fault) and System-Installers. SystemNavigation default obsoleteClasses -> an Array(AnObsoleteSARInstaller AnObsoleteBreakPoint AnObsoleteBreakpointManager AnObsoleteMczInstaller) The empty system and method categories should be removed. -- Pavel On Wed, Jun 30, 2010 at 7:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Pavel can you have a look to see if everything is ok? > > 12024 > ----- > > - Issue 2105: Â Packages remodularization > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

[Pharo-project] [update 1.2] #12024

by StÃ©phane Ducasse

Pavel can you have a look to see if everything is ok? 12024 ----- - Issue 2105: Packages remodularization

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by StÃ©phane Ducasse

Gerardo I already told you that in the past. We do not need XAML. in VW you have window spec and they are exactly the same without the need for XML <Button> <Button.Background> <SolidColorBrush Color="Blue"/> </Button.Background> <Button.Foreground> <SolidColorBrush Color="Red"/> </Button.Foreground> <Button.Content> This is a button </Button.Content> </Button> #(#{UI.ButtonSpec} #layout: #(#{Graphics.LayoutFrame} 25 0.35 30 0 90 0.35 53 0 ) #name: #newButton #model: #newPattern #label: #(#{Kernel.UserMessage} #key: #New #defaultString: 'New' #catalogID: #pdp) #defaultable: true ) in VW they use that since 1995 and this is working no need for XML. You get a spec object and then you interpret it to populate the builder canvas. Have a look at Builder design pattern because it is inspired from the UIBuilder class of Visualworks (or if this is not the case this is exactly the pattern application). Here is a more complex example of a spec. windowSpec "UIPainter new openOnClass: self andSelector: #windowSpec" <resource: #canvas> ^#(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #label: #(#{Kernel.UserMessage} #key: #ContextListPolicyEditor #defaultString: 'Context list policy editor' #catalogID: #pdp) #min: #(#{Core.Point} 528 401 ) #max: #(#{Core.Point} 1024 768 ) #bounds: #(#{Graphics.Rectangle} 592 427 1120 828 ) #flags: 4 #menu: #menuBar ) #component: #(#{UI.SpecCollection} #collection: #( #(#{UI.LabelSpec} #layout: #(#{UI.AlignmentOrigin} 0 0.175 5 0 0.5 0 ) #name: #PatternListLabel #label: #(#{Kernel.UserMessage} #key: #Patterns #defaultString: 'Patterns' #catalogID: #pdp) ) #(#{UI.SequenceViewSpec} #properties: #(#{UI.PropertyListDictionary} #dragOkSelector #wantToDrag: #dragEnterSelector #dragEnter: #dragOverSelector #dragOver: #dragStartSelector #doDrag: #dropSelector #drop: #dragExitSelector #dragLeave: ) #layout: #(#{Graphics.LayoutFrame} 2 0 30 0 0 0.35 -60 1 ) #name: #patternList #model: #patternList #menu: #menu #useModifierKeys: true #selectionType: #highlight ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 25 0.35 30 0 90 0.35 53 0 ) #name: #newButton #model: #newPattern #label: #(#{Kernel.UserMessage} #key: #New #defaultString: 'New' #catalogID: #pdp) #defaultable: true ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 115 0.35 30 0 180 0.35 53 0 ) #name: #removeButton #model: #removePattern #label: #(#{Kernel.UserMessage} #key: #Remove #defaultString: 'Remove' #catalogID: #pdp) #defaultable: true ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 13 0.35 105 0 -9 0.75 128 0 ) #name: #patternNameInput #model: #patternName ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 8 0.75 105 0 87 0.75 128 0 ) #name: #colorButton #model: #selectColor #label: #(#{Kernel.UserMessage} #key: #PickColor #defaultString: 'Pick Color' #catalogID: #pdp) #defaultable: true ) #(#{UI.TextEditorSpec} #layout: #(#{Graphics.LayoutFrame} 13 0.35 160 0 -8 1 -155 1 ) #name: #TextEditor1 #model: #patternString #tabRequiresControl: true ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 13 0.35 85 0 ) #name: #Label1 #label: #(#{Kernel.UserMessage} #key: #Name #defaultString: 'Name' #catalogID: #pdp) ) #(#{UI.LabelSpec} #layout: #(#{UI.AlignmentOrigin} 0 0.675 137 0 0.5 0 ) #name: #Label3 #label: #(#{Kernel.UserMessage} #key: #PatternString #defaultString: 'Pattern String' #catalogID: #pdp) ) #(#{UI.GroupBoxSpec} #layout: #(#{Graphics.LayoutFrame} 6 0.35 65 0 -2 1 -145 1 ) #name: #GroupBox1 #label: #(#{Kernel.UserMessage} #key: #Pattern #defaultString: 'Pattern' #catalogID: #pdp) ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 12 0.35 -118 1 0 0.679924 -92 1 ) #name: #matchSelectorInputField #model: #matchSelector #type: #symbol ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 6 0.68 -118 1 -8 1 -92 1 ) #name: #conversionSelectorInputField #model: #conversionSelector #type: #symbol ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 12 0.35 -137 1 ) #name: #Label4 #label: #(#{Kernel.UserMessage} #key: #MatchSelector #defaultString: 'Match Selector' #catalogID: #pdp) ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 6 0.68 -137 1 ) #name: #Label5 #label: #(#{Kernel.UserMessage} #key: #ConversionSelector #defaultString: 'Conversion Selector' #catalogID: #pdp) ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutSizedOrigin} -100 0.5 -33 1 80 23 ) #name: #okButton #model: #accept #label: #(#{Kernel.UserMessage} #key: #Ok #defaultString: 'Ok' #catalogID: #pdp) #defaultable: true ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutSizedOrigin} 20 0.5 -33 1 81 23 ) #name: #cancelButton #model: #cancel #label: #(#{Kernel.UserMessage} #key: #Cancel #defaultString: 'Cancel' #catalogID: #pdp) #defaultable: true ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 12 0.35 -82 1 ) #name: #Label2 #label: #(#{Kernel.UserMessage} #key: #DisplayAllLimit #defaultString: 'Display all limit' #catalogID: #pdp) ) #(#{UI.SpinButtonSpec} #layout: #(#{Graphics.LayoutFrame} 90 0.35 -83 1 150 0.35 -60 1 ) #name: #displayAllLimitField #model: #displayAllLimit #type: #number #formatString: '0' #low: 1 #high: 100 #interval: 1 ) #(#{UI.ActionButtonSpec} #layout: #(#{UI.AlignmentOrigin} -10 1 -10 1 1 1 ) #name: #HelpButton #model: #help #label: #(#{Kernel.UserMessage} #key: #Help #defaultString: 'Help' #catalogID: #pdp) #defaultable: true ) #(#{UI.DividerSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 -48 1 0 1 -44 1 ) #name: #Divider1 ) ) ) ) On Jun 30, 2010, at 3:35 PM, nullPointer wrote: > >> I dont understand. If you dont know the difference why did you change >> from MIT to BSD for CLFramework? > > No idea. I donÂ´t know the change but you has warning me. The license is already > changed to MIT. > >> Yes that would be good to know about the reasons. We know that you >> were not satisfied with your own code - but who of us really is? > > I believe the valid model for create a UIBUilder is implement something like WPF > in paint technology ( use OpenGL for paint and have 3D elements ) and XAML build > the UI in design time. I donÂ´t have knowledges for implement that, and I donÂ´t > know if is possible implement something like that on Pharo-Smalltalk; but I > believe that is needed for create something UIBuilder modern for > Pharo-Smalltalk, and not based on old systems. But that task is for people with > more knowledges. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by Schwab,Wilhelm K

If you are generating XML, perhaps that should be left to SIXX?? The result should be very close to Dolphin's ViewComposer, which is a very powerful tool. There are some traps to avoid with conversion of the serializer's output, but I can hopefully advise on where those might arise. It's unclear to me whether Dolphin's "recent" conversion to view resources as source code is a bad idea or simply under-supported in the area of conversion of existing view resources. Serializer output worked, with some caveats of dependence on layout changes and limitations on browsing into view resources, at least when they are in their dormant state. We are starting with real closures, dodging a bullet that hurt Dolphin. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Wednesday, June 30, 2010 9:15 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] CLFramework and Pharo On Wed, Jun 30, 2010 at 3:55 PM, nullPointer <epicfan(a)gmail.com<mailto:epicfan@gmail.com>> wrote: >> I believe is best create another from scratch, >> but with WPF like model and XAML >> as UI definition language. That is for people with best knowledges. > > I'm not convinced that we cannot learn from your development. Because is needed change the current exposition to something like that: http://www.youtube.com/watch?v=4-T-yF3tXCc&feature=related http://www.youtube.com/watch?v=RyO7v06xlWM&feature=related Forget for a moment that is from M$ XD The wonderful of that is the language for define the UI interface, XAML, where you can describe not only basic propertys of "morph" like colors or positions, but too animations, mouseOver effects, timers, movies... And you can use editors of XAML, external from environment, for create more rich UIs. I don't think WPF/XAML/whatever is good or bad (indeed I don't care :). But I think there's lot of value in having UIBuilder with "old mechanism" *now*. Do you think we can easily get it out of experimental / alpha state ? Or is there design/architecture mistakes such as thinking of creating applications with it is harmful ? For the future, something based on Morphic 3 isn't the right way ? Cheers, Laurent The current UIBuilder is based on old mechanism for build views, and surely with a lot of errors. I believe that that is the best direction for something more new and correct. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

[Pharo-project] [ANN 1.2] 1.2 12023 Unstable available

by StÃ©phane Ducasse

https://gforge.inria.fr/frs/download.php/27220/PharoCore-1.2-12023-UNSTABLE… Stef

June 30, 2010