- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiling the VM with Xcode 4.5.2

by Igor Stasenko

On 24 December 2012 17:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Has anyone successfully compiled the mac jit vm with Xcode 4.5.2? I want to > make sure it works before I upgrade... > I don't think so. You will be first :) > Thanks, > Sean > > > > -- > View this message in context: http://forum.world.st/Compiling-the-VM-with-Xcode-4-5-2-tp4660866.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Dec. 24, 2012

[Pharo-project] Compiling the VM with Xcode 4.5.2

by Sean P. DeNigris

Has anyone successfully compiled the mac jit vm with Xcode 4.5.2? I want to make sure it works before I upgrade... Thanks, Sean -- View this message in context: http://forum.world.st/Compiling-the-VM-with-Xcode-4-5-2-tp4660866.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by Igor Stasenko

On 24 December 2012 09:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello Igor > > Thank you for this interesting mail. An issue over 11 years old, see below. > > On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hi, >> >> just wanna share some ideas about how we can cleanup morph a bit. > > A bit? > It will be a lot of effort. > We can do it in small steps. > Squeak 4.4-12234 (current) > > Morph selectors size 1183 > > > Pharo 2.0 (Beta) > > Morph selectors size 865 > > > Cuis 4.1 (18th Dec 2012) > > Morph selectors size 343 > > > This was an issue in 2001 > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt > > see > I am not first day here, of course i am aware of this :) >> Layout.. bizarre. > > Yes, see humorous contribution from June 2001 > http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt > > search for > > the Morph class has 924 methods > > in that mails > > There was an effort > Morphic Cleanup Project > > http://wiki.squeak.org/squeak/3005 > > lead by > > Diego Gomez Deck > > It produced some results. But they did not reach far enough. > yes yes.. i know. > However Juan Vuletic was successful in coming up with a simpler Morphic in Cuis. > > http://www.jvuletich.org/Cuis/Index.html > search this mailing list for Small Morphic. It was an attempt to use Juan's work, which didn't fly. >> There are so many methods dedicated to laying out morphs that it easy >> to get lost. > > Cuis has a new layout system. > > Worth to check out. > Sure. >> For me the main mystery and source of confusion is that there actually >> two different groups: >> >> - methods to control morph's own layout (in respect to its parent) >> - methods to control morph's children layout (something called >> layoutPolicy) >> >> the problem is that both APIs are found in single class, > > which one? > Morph > and most of >> them contain 'layout' word in it, >> so it is really hard to determine which one to use and when.. >> >> Over a years, i seen that people learned how to use existing >> functionality, without delving deep into >> implementation detail. > > Yes. > >> But if you try to extend/change behavior (in your subclass), you will >> quite soon find out that it is really >> hard to tell with 100% certainty that the methods you override is the >> right place for your customization. > > Yes, this actually has made development very difficult. In such a way > that most people have abandoned it. Very few GUIs are actually built > with it. > > >> Also, an important detail is extremely polluted protocol(s), making >> Morph a GOD class, >> with so many functions that it is unbearable. > > > >> So, what i want to propose is same as i proposed to introduce for >> "SmalltalkImage" >> is to use "scoping" accessors , or "delegate" accessor to get access >> to part of functionality >> with clear context. > > Surely a good intermediary step. > >> Remember: >> Smalltalk vm version >> Smalltalk tools browser >> >> so, lets see how code might look like if we apply same approach to >> morph protocols: >> >> Example. >> Original: >> >> column := AlignmentMorph newColumn vResizing: #shrinkWrap; >> hResizing: #shrinkWrap; >> layoutInset: 1; >> borderColor: Color black; >> borderWidth: 0; >> wrapCentering: #center; >> cellPositioning: #center; >> color: Color white; >> yourself. >> >> Change: >> >> column := AlignmentMorph newColumn. >> >> column color: Color white. >> column layout shrinkWrap. "v and h both" >> >> column border >> width: 0; >> color: Color black. >> >> column childLayout >> inset: 1; >> wrapCentering: #center; >> cellPositioning: #center. >> >> Cons: >> - a code is a bit more elaborate. That because, of course, we cannot >> merge everything into single cascade. >> >> Pros: >> - from code it is clear, which properties belong to which parts of >> functionality. You cannot confuse, for instance, whether >> 'wrapCentering' >> property controls morph's own layout or a layout of its children >> - most important, we can considerably shrink Morph's protocol by >> removing all direct accessors and instead put them into delegated >> behaviors. >> >> More than that, a delegates don't need to be a dummy state holders >> (like most of properties are now), but actually an object(s) which >> conform to certain protocol.. >> >> For instance, if we have a 'border' as a delegate, and morph wants to >> draw it, it could just tell: >> >> MyMorph>>drawOn: aCanvas >> self border drawOn: aCanvas >> >> btw, then it is actually makes sense having a BorderedMorph subclass, which >> a) introduces 'border' delegate >> b) cares to draw its border >> in contrast to Morph who shouldn't. >> >> As well as in case of layouts, you can tell: >> >> morph layout changed. >> >> or >> >> morph childLayout layOutChildren. >> >> etc. >> >> > > I can't comment more at the approach at the moment. Could you > elaborate it a bit more? > mm.. can you tell, what is not clear to you? > As the leading example of Juan Vuletich shows it is possible to > reduce the complexity of Morphic. It would be good to check out what > he has written about his work. > I am sure that things i proposing not found in Cuis. > > Best regards > Hannes Hirzel > -- Best regards, Igor Stasenko.

Dec. 24, 2012

[Pharo-project] [update 2.0] #20454

by Marcus Denker

20454 ----- Issue 7165: CleanUp MethodChangeRecord http://code.google.com/p/pharo/issues/detail?id=7165 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1008.diff http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.196.diff

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by H. Hirzel

maybe - but with the Seaside web framework this was put to action. See Seaside weeb page. And there is a initial release of a follow up web framework to Seaside called 'Altitude'. See Squeak mailing list. And have a look at how the GUI in Cuis 4.1 is constructed. Pharo has the 'Glamour' browser construction framework. It is very well documented and put to use in the 'Moose' image. HTH to give some things to try out. --Hannes Pharo was and still is positioned as a Smalltalk IDE and a server side tool. On 12/24/12, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > > >> And our goal is not just to be Smalltalk because there are probably design >> decisions that were not suitable >> in 1980 that are now possible. > > What does this mean ? You mean that the solution to the GUI should be web > based (Js / Html5) ? >

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by StÃ©phane Ducasse

On Dec 24, 2012, at 12:16 PM, dimitris chloupis wrote: > > > > And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > > in 1980 that are now possible. > > What does this mean ? You mean that the solution to the GUI should be web based (Js / Html5) ? it means nothing special. Just do it. You know a keyboard and a man. Or a group of programmers that want to get something done. So I will not continue to talk because I want to keep my time to hack. Sorry but pair programming is too fun and I have some legos to build before igor show up Stef

Dec. 24, 2012

Re: [Pharo-project] [squeak-dev] Re: About (backwards) Compatibility

by Bert Freudenberg

On 2012-12-23, at 15:39, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 December 2012 11:16, Andreas.Raab <andreas.raab(a)gmx.de> wrote: >> Igor Stasenko wrote >>> yes, i want string math, because at the end, everything you type into >>> machine is strings, so having objects, classes or compiled methods >>> seems like overcomplication, when you can do the same by just using >>> stings.. >>> We definitely should reconsider "everything is an object" postulate, >>> instead we should postulate "everything is string", >>> otherwise smalltalk will never be a successful platform like >>> javascript/perl etc. >>> >>> oh, yes, and while we're changing that, please add the 'math' precedence >>> rules, >>> because my math teacher is the school told me that this is the only >>> right way they should be processed, >>> oh, and at last, lets use curly braces syntax because it is sooo >>> convenient. >> >> Could you move your trolling attempts to the pharo list please? >> > First. It was not trolling attempt, but sarcasm attempt. :) I thought it was funny :) > Second. The topic was originally from pharo list. > I don't know why people moved discussion it on squeak-dev list. > I just replying. > But thanks for reminder that i am not welcome here anymore. Nah, you are most certainly welcome. Andreas was just misreading you. - Bert -

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by dimitris chloupis

> And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > in 1980 that are now possible. What does this mean ? You mean that the solution to the GUI should be web based (Js / Html5) ?

Dec. 24, 2012

Re: [Pharo-project] About morph layout

by Sven Van Caekenberghe

On 24 Dec 2012, at 11:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hannes > > this is exactly for these reasons that we started Pharo. We want to have a clean and powerful system. > Now in addition we want to make sure that people can make business with it. > And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > in 1980 that are now possible. +10 > Now I think that Pharo delivers. We will continue. +100 Very well said, quotable material ! > Stef Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 24, 2012

[Pharo-project] Is there a simple example of how to create a GUI form in Pharo or Squeak?

by Frank Church

Is there a simple example of how to create a GUI form in Pharo or Squeak? I want to accomplish a simple task with a form: 1. Create a form with a button and edit control and 2 text areas. 2. Enter a value into the edit control. 3. Run a database query using the value in the edit control as a parameter and return the results in text area 1 4. Run a shell script using the value in the edit control as a parameter and return the results in text area 2 I have OpenDBX running successfully and I don't think using OSProcess and CommandShell will be that difficult. Creating the form is the part I don't know how to accomplish. I have done some searching and there seems to be a surprising dearth of info on how to create a simple GUI from scratch using Pharo or Squeak. -- Frank Church ======================= http://devblog.brahmancreations.com

Dec. 24, 2012