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

Re: [Pharo-project] Initial experience coming from Squeak

by Sean P. DeNigris

Lukas Renggli wrote: > > I don't see why not pre-selecting the template helps? I've quickly > changed that, but clicking on it doesn't select it. > If the template is not pre-selected, single clicking off the template (in the pane below the bottom of the template) selects it. Also, I think pre-selecting when there's no possible way to make use of the pre-selection is kind of mean, like dangling a banana outside a monkey cage, lol. Sean -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p183563… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 10, 2010

Re: [Pharo-project] [squeak-dev] Re: SqueakSource is unusable

by Bert Freudenberg

On 10.04.2010, at 21:19, stephane ducasse wrote: > > > On Apr 10, 2010, at 7:16 PM, Bert Freudenberg wrote: > >> Thanks. >> >> I just merged the stuff I developed lately > > which is? Most importantly, projects can have parent projects now (only if a site-wide setting is enabled). This is to support "inbox" style use - when mailing out diffs, the diff based is searched in a project's parent project too. Also, you can enable developers to move versions, not just admins. This is a per-project setting, again to enable developers to clean out an "inbox" repository. There can also be a default target project for moves. Since SSProject grew too many instance variables, I added a properties dictionary just like we have for versions and repositories. Refactoring might be in order but I just copied and pasted. Sorry ;) There are a few minor changes, see the version history :) - Bert -

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by StÃ©phane Ducasse

I think that this is a bad sign for a lot of languages. The analysis on the move against flash and adobe are interesting. This is also a problem for company selling game dev platform. Bad. Stef >> >> On 2010-04-10, at 9:08 AM, Stefan Marr wrote: >> >>> There are rumors, that this change is motived by technical reasons related to multitasking. >>> I could imagine some nice tricks related to the efforts Apple is putting into LLVM, to actually have a 'smart' C/C++ runtime system which allows to assess what kind of activity profile an app is going to exhibit. >>> This is already hard enough with C, prohibiting any VM technology seems to be a reasonable step, if they are actually going to employ any analysis techniques to get their multitasking stuff 'right'. >>> >>> But this is pure speculation. >>> >>> In the light of Steve Job's remark: "We just shipped it on Saturday, and we rested on Sunday." everything is possible, even that he is just going... >>> >>>>> http://www.macrumors.com/2010/04/09/fallout-from-apples-exclusion-of-flash-… >>> The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app. >>> >>> "[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe. >>> << >> >> Nonsense. >> >> An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. > > +1.. this is a bullshit. > Instead of solving the problem, they locking-down their platform. > > Its like saying "we're going to build an aircrafts with 4 wings, and > from this moment, all two-winged planes should stop being used > worldwide". > >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 10, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by StÃ©phane Ducasse

Hi richard some changes are changes coming from squeak and in such a case there is the squeak change It does not mean that we can integrate the change as it is. Thanks for looking at fixes and bug entries Stef On Apr 10, 2010, at 7:52 PM, Richard Durr wrote: > I am still trying to grok how this issue-fixing works. For example, in > "Difficulty:Easy" there are some issues which consist mostly of > ChangeSets of something. O_o O_o Nice :) > > On Tue, Apr 6, 2010 at 10:50 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes this is the vision we have. >> Now if people would help for simple things in pharo we would have more time for such issues. >> We got several people doing PhD on modules and related. We studied namespace and other kind of >> points so we have an idea of what could be a solution but it should be implemented >> tested..... >> >> Stef >> >> >> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote: >> >>> No, it's not. I would be far more valuable to have modularized images >>> though: Just like Next/Apples Nibs or Bundle-mechanism. These >>> image-modules would be edited from a development-image-bundle. They >>> could be used to form stand-alone applications already clean of the >>> development code or libraries that contain only a diff to the base >>> classes, these library-images could then be combined to form more >>> complex images. They could also contain their own namespaceâ¦ and they >>> would replace the non-modelling packaging mechanism, but I digressâ¦ ^^ >>> >>> | packageWorkedOn | >>> packageWorkedOn := Browser newPackageNamed: 'Calculator'. >>> packageWorkedOn importPackage: 'Seaside'. >>> "Create code in the Browserâ¦" >>> packageWorkedOn saveAsMonticello. >>> packageWordedOn saveAsPackage. >>> packageWorkedOn saveAsApplication. >>> >>> or something like that â¦ ^^ >>> >>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan(a)gmail.com> wrote: >>>> >>>> jarober says: >>>> >>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >>>>> projects never seem to come off is simple - Smalltalk isn't just flat >>>>> text in an editor. Smalltalk is the entire interactive environment. >>>>> It would be fairly simple to get a syntax parser, but it wouldn't be >>>>> Smalltalk. It would be Ruby or Python with Smalltalk syntax. >>>>> Somewhat useful perhaps, but not really Smalltalk. >>>> >>>> :( >>>> >>>> Hopefully it would have sufficient knowledge to be able to do something >>>> thus. >>>> >>>> Sorry, but I believe that it is the way that had to take commercial >>>> Smalltalk. It surprises to me that Cincom and company do not see it. >>>> >>>> Regards. >>>> -- >>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by Igor Stasenko

2010/4/10 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > On 2010-04-10, at 9:08 AM, Stefan Marr wrote: > >> There are rumors, that this change is motived by technical reasons related to multitasking. >> I could imagine some nice tricks related to the efforts Apple is putting into LLVM, to actually have a 'smart' C/C++ runtime system which allows to assess what kind of activity profile an app is going to exhibit. >> This is already hard enough with C, prohibiting any VM technology seems to be a reasonable step, if they are actually going to employ any analysis techniques to get their multitasking stuff 'right'. >> >> But this is pure speculation. >> >> In the light of Steve Job's remark: "We just shipped it on Saturday, and we rested on Sunday." everything is possible, even that he is just going... >> >>>> http://www.macrumors.com/2010/04/09/fallout-from-apples-exclusion-of-flash-… >> The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app. >> >> "[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe. >> << > > Nonsense. > > An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. +1.. this is a bullshit. Instead of solving the problem, they locking-down their platform. Its like saying "we're going to build an aircrafts with 4 wings, and from this moment, all two-winged planes should stop being used worldwide". > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: Â squeaker68882 > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by John M McIntosh

See http://en.wikipedia.org/wiki/Kill_(command) for discussion of kill suspend/resume. The simple case is likely the unix process scheduler sends you a suspend, later a resume if it chooses to wake you up, otherwise a resume and quit. The more complex cases are when you want to do audio, voip, or location. In this case you are setting up an agreement between the app and the scheduler to wake you when audio needs servicing, a socket requires keep-alive & traffic in processing, or a change to location is made. Part of that agreement is restrictions on what you can do in the background, like no UI or openGL work, no listening sockets, etc.. Again the unix process manager here may re-nice you to a lower priority if you do too much, or decide you are a nuance and kill you. Obviously Apple may when testing decide that your app uses too much CPU as a background process and not approve. You can ask for a limited amount of time to run as a background task when you are shoved to the background, but that is finite. In general the idea is that you are waken to processes audio, location, and socket interrupts, from an event driven expectation and you go back to sleep once the chore is done. On 2010-04-10, at 10:27 AM, Stefan Marr wrote: >> Nonsense. >> >> An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. > Ehm is it that easy? I don't know the internals of their new stuff. But when I read the announcement, it sounded more like they want you to provide 'kind of services', so that only part of your app needs to stay alive in the background, for instance to play music, or track location data. But you cannot just swap out/deschedule the whole process, at least not in a model which uses threads instead of processes. > > But I am just guessing... -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 10, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by Richard Durr

I am still trying to grok how this issue-fixing works. For example, in "Difficulty:Easy" there are some issues which consist mostly of ChangeSets of something. O_o On Tue, Apr 6, 2010 at 10:50 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes this is the vision we have. > Now if people would help for simple things in pharo we would have more time for such issues. > We got several people doing PhD on modules and related. We studied namespace and other kind of > points so we have an idea of what could be a solution but it should be implemented > tested..... > > Stef > > > On Apr 6, 2010, at 1:14 AM, Richard Durr wrote: > >> No, it's not. I would be far more valuable to have modularized images >> though: Just like Next/Apples Nibs or Bundle-mechanism. These >> image-modules would be edited from a development-image-bundle. They >> could be used to form stand-alone applications already clean of the >> development code or libraries that contain only a diff to the base >> classes, these library-images could then be combined to form more >> complex images. They could also contain their own namespaceâ¦ and they >> would replace the non-modelling packaging mechanism, but I digressâ¦ ^^ >> >> | packageWorkedOn | >> packageWorkedOn := Browser newPackageNamed: 'Calculator'. >> packageWorkedOn importPackage: 'Seaside'. >> "Create code in the Browserâ¦" >> packageWorkedOn saveAsMonticello. >> packageWordedOn saveAsPackage. >> packageWorkedOn saveAsApplication. >> >> or something like that â¦ ^^ >> >> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan(a)gmail.com> wrote: >>> >>> jarober says: >>> >>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >>>> projects never seem to come off is simple - Smalltalk isn't just flat >>>> text in an editor. Â Smalltalk is the entire interactive environment. >>>> It would be fairly simple to get a syntax parser, but it wouldn't be >>>> Smalltalk. Â It would be Ruby or Python with Smalltalk syntax. >>>> Somewhat useful perhaps, but not really Smalltalk. >>> >>> :( >>> >>> Hopefully it would have sufficient knowledge to be able to do something >>> thus. >>> >>> Sorry, but I believe that it is the way that had to take commercial >>> Smalltalk. It surprises to me that Cincom and company do not see it. >>> >>> Regards. >>> -- >>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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 >

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by Stefan Marr

> Nonsense. > > An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. Ehm is it that easy? I don't know the internals of their new stuff. But when I read the announcement, it sounded more like they want you to provide 'kind of services', so that only part of your app needs to stay alive in the background, for instance to play music, or track location data. But you cannot just swap out/deschedule the whole process, at least not in a model which uses threads instead of processes. But I am just guessing... > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 10, 2010

Re: [Pharo-project] SqueakSource is unusable

by Bert Freudenberg

Thanks. I just merged the stuff I developed lately for our Squeak source server with Lukas' latest (lr.1038) and published back to the shared repository. But the new layout was not in there yet. - Bert - On 10.04.2010, at 10:17, Michael Haupt wrote: > > Hi, > > why not just forward it to squeak-dev? Like this? > > Best, > > Michael ;-) > > Am 10.04.2010 um 09:16 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Thanks jason >> >> I do not know who is in charge of Squeak source nowadays. >> Adrian lukas do you know it? >> >> Stef >> >> On Apr 10, 2010, at 6:38 AM, jaayer wrote: >> >>> or if not that, then nearly so. >>> >>> The biggest problem is the overall smallness of each page. The site is far too narrow and apparently was designed for monitors with 800x600 screen resolutions. This was unacceptable five years ago and is even more unacceptable now. Further, the fonts are tiny, and worse, they and almost every other sized property are specified using hard-coded pixel widths. For scalable, cross-platform design, percentages and em-widths should be preferred. Links should display some sort of text-decoration when moused-over so it is always clear which link will be selected when the user clicks, even when two or more links are especially close together. SqueakSource is, after the primary home pages, the public face of the Squeak and Pharo projects. It is crucial then that it look--if not great--at least decent. Enclosed is prettified CSS that fixes some of these defects. (Note that Image url() references need to be filled in, and it still probably needs some tweaking.) >>> >>> body { >>> border:0; >>> background:gray; >>> text-align:center; >>> margin:0; >>> padding:10px; >>> font-size:0.9em; >>> } >>> >>> body,div,table,tr,td,th,form input,form submit { >>> font-family:Geneva, Arial, Helvetica, sans-serif; >>> } >>> >>> table,tr,td,th,form { >>> border:0; >>> margin:0; >>> padding:0; >>> } >>> >>> th { >>> text-align:left; >>> } >>> >>> a,a:visited { >>> color:#360484; >>> text-decoration:none; >>> } >>> >>> a:hover,a:active { >>> text-decoration:underline; >>> } >>> >>> #container { >>> width:90%; >>> background:white url(/inserturl) repeat-y 4%; >>> border:1px solid black; >>> border-top:5px solid black; >>> border-bottom:5px solid black; >>> text-align:left; >>> margin:auto; >>> } >>> >>> #top { >>> width:100%; >>> height:50px; >>> background:url(/inserturl) no-repeat; >>> border-bottom:1px solid black; >>> font-size:0.7em; >>> text-align:right; >>> } >>> >>> #sstoolbar { >>> height:2em; >>> border-bottom:1px solid black; >>> background:white; >>> } >>> >>> #sstoolbar a { >>> display:block; >>> float:left; >>> margin-left:-1px; >>> border-left:1px solid black; >>> border-right:1px solid black; >>> line-height:2em; >>> height:2em; >>> letter-spacing:1px; >>> text-decoration:none; >>> padding:0px 10px; >>> } >>> >>> #sstoolbar a:hover,#sstoolbar a:active { >>> background-color:#360484; >>> color:white; >>> text-decoration: none; >>> } >>> >>> #page { >>> padding:0; >>> } >>> >>> #page td,#page th { >>> padding-right:5px; >>> vertical-align:top; >>> } >>> >>> #navigation { >>> float:left; >>> width:12%; >>> padding:0 10px 10px 10px; >>> } >>> >>> #navigation .title { >>> margin-top:11px; >>> font-weight:bold; >>> } >>> >>> #contents { >>> width:70%; >>> height:auto; >>> text-align:justify; >>> margin:0 0 0 16%; >>> padding:5px 10px 10px; >>> } >>> >>> #contents h1 { >>> margin-top:0; >>> font-size:20px; >>> } >>> >>> #contents h2 { >>> margin-bottom:5px; >>> font-size:15px; >>> } >>> >>> #contents h3 { >>> margin-bottom:5px; >>> font-size:13px; >>> } >>> >>> #contents hr { >>> border:none; >>> border-bottom:1px dotted black; >>> } >>> >>> #contents p { >>> width:90%; >>> } >>> >>> #bottom { >>> padding-left:5px; >>> padding-right:5px; >>> clear:both; >>> border-top:1px solid black; >>> background:white; >>> margin:0; >>> } >>> >>> .TabSelected { >>> background-color:#360484; >>> color:white; >>> width:95px; >>> text-align:center; >>> } >>> >>> .TabUnselected { >>> background-color:#D0C4E2; >>> width:95px; >>> text-align:center; >>> } >>> >>> .TabSpacer { >>> width:5px; >>> } >>> >>> .TabLine { >>> background-color:#360484; >>> } >>> >>> #batch { >>> text-align:center; >>> margin-top:8px; >>> } >>> >>> .evenRow { >>> background-color:#E7E1F0; >>> } >>> >>> .largeLabel { >>> width:120px; >>> } >>> >>> .mediumLabel { >>> width:100px; >>> } >>> >>> .smallLabel { >>> width:80px; >>> } >>> >>> .activityTable { >>> margin-left:auto; >>> margin-right:auto; >>> } >>> >>> #window-titlebar { >>> background-color:#D0C4E2; >>> margin-bottom:10px; >>> width:100%; >>> } >>> >>> #window-title { >>> text-align:right; >>> width:66%; >>> } >>> >>> #window-close { >>> text-align:right; >>> } >>> >>> .column-choice select { >>> min-width:15em; >>> } >>> >>> >>> _______________________________________________ >>> 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

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by John M McIntosh

On 2010-04-10, at 9:08 AM, Stefan Marr wrote: > There are rumors, that this change is motived by technical reasons related to multitasking. > I could imagine some nice tricks related to the efforts Apple is putting into LLVM, to actually have a 'smart' C/C++ runtime system which allows to assess what kind of activity profile an app is going to exhibit. > This is already hard enough with C, prohibiting any VM technology seems to be a reasonable step, if they are actually going to employ any analysis techniques to get their multitasking stuff 'right'. > > But this is pure speculation. > > In the light of Steve Job's remark: "We just shipped it on Saturday, and we rested on Sunday." everything is possible, even that he is just going... > >>> http://www.macrumors.com/2010/04/09/fallout-from-apples-exclusion-of-flash-… > The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app. > > "[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe. > << Nonsense. An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 10, 2010