- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Automatic generation of abstract methods

by Denis Kudriashov

And there is DynamicProtocols. Which show abstract methods and more 2010/4/12 Simon Denier <Simon.Denier(a)inria.fr> > > On 12 avr. 2010, at 14:26, Cyrille Delaunay wrote: > > > Hello, > > > > Would it be difficult to generate automatically superclass-abstract > methods (with an empty contents) when creating a new subclass? > > For example, imagine I want to make my own subclass of Collection. As > there is a lot of methods in this class and probably abstract methods, it > would be cool to see them directly in my subclass without having to look to > Collection method one by one (?). > > I'm probably not the first to ask this question, but in case it is, > that's done:) > > > Normally there is already a refactoring for that. Context menu>refactor > class>realize > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 22, 2010

Re: [Pharo-project] [Vm-dev] CMake for Windows?

by laurent laffont

On linux, configure fails: -- Configuring done CMake Error in CMakeLists.txt: Cannot find source file "aio.c". Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx aio.c is in .unix/vm/aio.c Cheers, Laurent Laffont On Thu, Apr 22, 2010 at 7:23 AM, Geoffroy Couprie <geo.couprie(a)gmail.com>wrote: > > Ping! > > I know everyone is busy, but could someone test these CMake files? I > can't install a VM to build unix Squeak right now, but I'll do it in > the future. > > I just want to know if it's still possible to create unix squeak with > these files :) > > On Sat, Apr 17, 2010 at 1:23 AM, Geoffroy Couprie <geo.couprie(a)gmail.com> > wrote: > > Hello, > > > > You'll find my work on the CMake files at > > http://eleves.ec-lille.fr/~couprieg/divers/patches.zip > > > > I put a CMakeLists.txt file just under the platforms/ directory, along > > with the cmake/ directory. These files are based on the unix ones. I > > modified them to change the source directory depending on the > > platform. I also modified the configure file accordingly, but i > > commented the code using subversion for my convenience during > > development (feel free to change it back). > > > > These CMake files are not perfect, it's just the beginning. First, I > > want to make sure that the unix port still builds with my file, and > > then, I'll go on with the config.cmake and build.cmake files for the > > plugins, and I'll clean CMakeLists.txt a bit. > > > > Feel free to comment, but note that I'm beginning with CMake, and that > > I don't write bash code very often. And please, try it with the unix > > port. I don't want to break everything :) > > > > Anyway, it works for me here (I can build a VM on Windows with the > > File, Security, LargeIntegers and MiscPrimitive plugins using > > MSYS+MinGW). > > > > Best regards, > > > > Geoffroy > > >

April 22, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by Henrik Sperre Johansen

On 22.04.2010 04:45, Sean P. DeNigris wrote: > > I was looking for a SystemNavigator>> allMethodsUsingPragma: aSymbol, or > something like that. With that funtionality, I guess it really wouldn't > matter where they were located - or am I missing an easy way to find these > methods? > > Sean You could try PragmaCollector, which is quite neat. (PragmaCollector filter: [:pragma | pragma keyword = #worldMenu]) reset The problem with an allMethodsUsingPragmaWithKeyword: method, would be that people might think it was ok to use without caution, which it's not :) [100 timesRepeat: [PragmaCollector allSystemPragmas]] timeToRun 6245 So when using pragmas, a good idea is to either use a PragmaCollector like a cache (dynamically updated one, that is), or limit the search scope of the pragmas you accept, usually to a class. PragmaCollector does not exist in Squeak though, it's one of the pieces I think they'd find useful too. In fact, currently they have one implemented in methods on Preferences, in the "dynamic preferences" category. Class-scoped pragmas is what is used in VW for menu building. Cheers, Henry

April 22, 2010

Re: [Pharo-project] [Vm-dev] CMake for Windows?

by Geoffroy Couprie

Ping! I know everyone is busy, but could someone test these CMake files? I can't install a VM to build unix Squeak right now, but I'll do it in the future. I just want to know if it's still possible to create unix squeak with these files :) On Sat, Apr 17, 2010 at 1:23 AM, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: > Hello, > > You'll find my work on the CMake files at > http://eleves.ec-lille.fr/~couprieg/divers/patches.zip > > I put a CMakeLists.txt file just under the platforms/ directory, along > with the cmake/ directory. These files are based on the unix ones. I > modified them to change the source directory depending on the > platform. I also modified the configure file accordingly, but i > commented the code using subversion for my convenience during > development (feel free to change it back). > > These CMake files are not perfect, it's just the beginning. First, I > want to make sure that the unix port still builds with my file, and > then, I'll go on with the config.cmake and build.cmake files for the > plugins, and I'll clean CMakeLists.txt Â a bit. > > Feel free to comment, but note that I'm beginning with CMake, and that > I don't write bash code very often. And please, try it with the unix > port. I don't want to break everything :) > > Anyway, it works for me here (I can build a VM on Windows with the > File, Security, LargeIntegers and MiscPrimitive plugins using > MSYS+MinGW). > > Best regards, > > Geoffroy >

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Andreas Raab

On 4/21/2010 4:32 AM, Hannes Hirzel wrote: > A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? > Or if there is a difference what is the impact of it? > > Or put the question in another way. If I code an UI using the > ToolBuilder in Squeak 4.1 will it run in Pharo? They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). Cheers, - Andreas

April 22, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > Alain is our setting expert and we gotstuck on the how do write a setting > chapter. > So I'm happy other people like you push this further. > My experience as a settings beginner. It was actually really easy because: * '*setting*' is used everywhere, so I did a 'class find' and immediately found the settings categories * there are a lot of examples all together in the settings categories I think the hardest thing was the "xxxOn: aBuilder <pragma>" concept in general (same goes for the new world menu) - it's not immediately obvious (via my typical highlight and "browse it" method) where to look for the class that scooped all the setting methods up and built the browser. I remember my initial thought was "now what would I look under to find the thing that generates and passes in aBuilder?" Also, I think this model of keeping settings in separate packages is definitely easier from a learning perspective because you have all working examples in the same place. When I implemented my first worldMenu pragma method, it took a while to figure out how to generate a list of all methods currently using <worldMenu> so I could see how it was done. I was looking for a SystemNavigator >> allMethodsUsingPragma: aSymbol, or something like that. With that funtionality, I guess it really wouldn't matter where they were located - or am I missing an easy way to find these methods? Sean -- View this message in context: http://n4.nabble.com/Fix-2329-Default-MC-Directory-Setting-tp2019559p201995… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2010

Re: [Pharo-project] Hints and clues for a Pharo newb

by Eliot Miranda

On Wed, Apr 21, 2010 at 4:34 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > 2010/4/21 Lukas Renggli <renggli(a)gmail.com>: > >> thisContext is a special object for representing an activation in a > >> stack frame in a stack-based VM. > > > > Actually "thisContext" represents *the current* activation/stack-frame. > > > > foo: anObject > > ^ thisContext at: 1 > > > > is the same as > > > > foo: anObject > > ^ anObject > > > > Of course, "this" refers to "the current" in common language usage. > > >> There are two kinds of contexts: > >> Method Contexts and Block Contexts. > > > > Actually in Pharo images there are only instances of MethodContext. > > Though you can ask the context if it comes from a block by sending the > > message #isExecutingBlock. > > > > Actually in Pharo there is a BlockContext class, which is not > instantiated anymore after the introduction of the closure compiler? > Right. > In other Smalltalks aBlockContext is the resulting context of a block > activation during its evaluation and is activated by sending > #value,.this fills thisContext with the execution information inside > the block. > and it is now with the closure compiler. Or rather a new context is created when a BlockClosure is sent the value message. The context is an instance of methodContext though. > In Squeak (or the old compiler) block contexts were created using > #blockCopy:, now I see #closureNumCopied:numArgs:. Does this means > BlockContext could be completely removed and replaced with > MethodContext semantics? I've removed the BlockContext class and used > Pharo a little bit with no problems, maybe some Decompiler issues in > the Debugger... > Yes. But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block). If nil, ^-returns return to the context's sender. If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var. So we no longer need BlockContext. This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class. Possibly the name should be ExecutionContext or MethodOrBlockContext or? Suggestions? > Now, test yourself before evaluating :) what should be the result of > this expression? > > [: arg | arg perform: #isExecutingBlock ] value: thisContext > It depends on whether the expression is executed at method level or at block level. As a test this should be: testIsExecutingBlock self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false. [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value Can somebody justify the result? > isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not. Remember that [:arg| arg == thisContext] value: thisContext is false. thisContext is rebound within every actual method or block scope. HTH Eliot > >> Context creation is optimized in the VM in most Smalltalks, so it's > >> only really created as an object in the environment (reified) when > >> it's specifically needed through "thisContext". > > > > In Pharo contexts are not reified like that. Stack-frames are actual > > objects at all times. However, for speed reasons, their creation and > > garbage-collection is optimized by the VM. Stack frames get > > automatically recycled if nobody refers to them. > > > > I think is what I said :) > But its not a property of Pharo. It is a property of the VM. In Cog contexts are not actual objects all the time, only when needed. And Cog runs Pharo images just as it runs Squeak images. So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM". > >> There are several applications related with computational reflection > >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use > >> of the current context. > > > > Also: exception handling, generators, continuations, co-routines, ... > > > > For another fun use of "thisContext" check this Stack-Overflow question: > > > > > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only… > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > 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 22, 2010

Re: [Pharo-project] Hints and clues for a Pharo newb

by HernÃ¡n Morales Durand

2010/4/21 Lukas Renggli <renggli(a)gmail.com>: >> thisContext is a special object for representing an activation in a >> stack frame in a stack-based VM. > > Actually "thisContext" represents *the current* activation/stack-frame. > > Â Â foo: anObject > Â Â Â Â ^ thisContext at: 1 > > is the same as > > Â Â foo: anObject > Â Â Â Â ^ anObject > Of course, "this" refers to "the current" in common language usage. >> There are two kinds of contexts: >> Method Contexts and Block Contexts. > > Actually in Pharo images there are only instances of MethodContext. > Though you can ask the context if it comes from a block by sending the > message #isExecutingBlock. > Actually in Pharo there is a BlockContext class, which is not instantiated anymore after the introduction of the closure compiler? In other Smalltalks aBlockContext is the resulting context of a block activation during its evaluation and is activated by sending #value,.this fills thisContext with the execution information inside the block. In Squeak (or the old compiler) block contexts were created using #blockCopy:, now I see #closureNumCopied:numArgs:. Does this means BlockContext could be completely removed and replaced with MethodContext semantics? I've removed the BlockContext class and used Pharo a little bit with no problems, maybe some Decompiler issues in the Debugger... Now, test yourself before evaluating :) what should be the result of this expression? [: arg | arg perform: #isExecutingBlock ] value: thisContext Can somebody justify the result? >> Context creation is optimized in the VM in most Smalltalks, so it's >> only really created as an object in the environment (reified) when >> it's specifically needed through "thisContext". > > In Pharo contexts are not reified like that. Stack-frames are actual > objects at all times. However, for speed reasons, their creation and > garbage-collection is optimized by the VM. Stack frames get > automatically recycled if nobody refers to them. > I think is what I said :) >> There are several applications related with computational reflection >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use >> of the current context. > > Also: exception handling, generators, continuations, co-routines, ... > > For another fun use of "thisContext" check this Stack-Overflow question: > > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only… > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2010

Re: [Pharo-project] HelpSystem (was Documentation Team)

by Michael Roberts

yes I think that is a nice idea. we would need to see how it fitted in with http://pharo-project.org/documentation as it is currently, and if we load cms-box with all content or something else for dynamically generated stuff like your seaside example (or -> static html). cheers, Mike 2010/4/21 laurent laffont <laurent.laffont(a)gmail.com>: > Yes, Python documentation is really impressive, the best I know. > May be we can go the other way, from HelpSystem to web. I've tried something > like some months > ago.ex:Â http://magaloma.seasidehosting.st/Collections-Streams. > So we can have a documentation page likeÂ http://docs.python.org/py3k/Â with: > - collaborator book > - web edition of Pharo By Example > - HelpSystem books > - API reference generated from comments in classes / methods (with the > possibility to add comments like Â jQuery or PHP online docs.) > All on one page, starting point to look for documentation, at > http://docs.pharo-project.org > Cheers, > Laurent Laffont > > > On Wed, Apr 21, 2010 at 10:46 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >> >> Laurent, i think this is a tension that a number of us feel. should we >> put documentation in the colab book, or in the system? For me the two >> are distinct. Â The book, ultimately, should read as a book. That is >> there is a logical flow from start to finish and the content is >> consistent, from start to finish, for a given version of the system. >> Writing a book appears hard - i have never done it - but i have >> attempted to copy-edit material that turned out to be as big as a >> reasonably sized book; i found that near impossible. Â So whilst the >> colab book effort is currently in its infancy, i would expect over >> time it to tend towards being published as a consistent whole. I'm >> sure anyone involved in SBE/PBE could comment on the real work >> required to write such a book. >> >> As for help in the system, as torsten nicely articulated either "Help" >> or "Reference", this should really be dynamic. It should change at the >> unit of which it is changing. so if a new version of a package is >> loaded, perhaps the Reference docs change. using hyperlink references >> you should be able to jump around it in an arbitrary order. Â I don't >> see a book performing this function. really it must flow consistently >> from start to finish and the layout of the book is carefully picked by >> the editors. the only realy hyperlink function is from the TOC, and to >> any particular index or reference. it is quite distinct from arbitrary >> jumping at a system doc level. >> >> at the moment these two forces I consider are at tension, because >> there is not enough reference material in the system as we shipped >> 1.0, and i think the barrier to viewing & editing such reference >> documentation, as a coherent whole, to my satisfaction is harder than >> using Pier. therefore i find it easier to edit pier even if i have >> only contributed a few paragraphs. however longer term this will not >> be the case. Â We must strive for something akin to Python >> documentation. as an engineering artifact, it is simply stunning; you >> can find documentation on anything to do with a given released >> version. i'm sure this applies to other languages too, i just use >> python as an example because I particularly like its style towards doc >> annotation and its completeness. >> >> so personally i don't think we should export the pier content into the >> help system. i see them as quite different, and for both to succeed I >> think they require a different point of view to writing the content. >> >> Torsten - i did not reply to the other thread which stef and I both >> commented on, have not had the time. For me i am a total pragmatist >> when it comes toward reference documentation and i am only really >> interested in reference docs. i fully understand your design and i'm >> fine with that. I just hope that as a community we can author the >> reference side, since that is what i feel is most missing. >> >> cheers, >> Mike >> >> 2010/4/21 laurent laffont <laurent.laffont(a)gmail.com>: >> > Hi, >> > It's cool to have so many interests in documentation. I deeply think >> > it's a >> > key point to success. >> > As an hobbyist contributor to Pharo documentation :) I wonder whether I >> > should write doc in HelpSystem (which indeed is very cool !) or in the >> > collaborator active book (which is very attractive for me). >> > So a way to get the best of both world may be to generate an HelpSystem >> > book >> > from the collaborator book. Every day, if there has been changes in the >> > collaborative book, it can be "packaged" automatically as an HelpSystem >> > book >> > / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem >> > project >> > lastVersion pointing to the last package. >> > Sounds good ? >> > Cheers, >> > Laurent Laffont >> > >> > >> > On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann <astares(a)gmx.de> >> > wrote: >> >> >> >> To clearify a few things from my side on the discussion >> >> on squeak-dev: >> >> >> >> Â 1. HelpSystem is working, if ASCII is OK for now we can use >> >> Â Â it Pharo/Squeak - otherwise I would see it as an early preview. >> >> Â Â I have clear goals how it should look like in the >> >> Â Â next iterations. For this more patience is necessary. >> >> >> >> Â 2. HelpSystem is independent from where and how the actual >> >> Â Â information is stored (I think I demonstrated this with >> >> Â Â the IRC example, the books and the API help). >> >> >> >> Â 3. I hope to keep HelpSystem in sync for major Squeak distributions >> >> Â Â (Squeak, Pharo, Cuis, ...) >> >> >> >> Â Â The last additions from Hannes already broke the code >> >> Â Â in Pharo. Seems to be a Pharo issue this time >> >> Â Â http://code.google.com/p/pharo/issues/detail?id=2342 >> >> >> >> Â Â But please dont commit when it is only working in >> >> Â Â Squeak since my development environment is Pharo. >> >> >> >> Â 4. Yes, the content is currently ASCII but the design is prepared >> >> Â Â to add other types in future releases. >> >> >> >> Â Â A HelpTopic defines an ivar "contents" - currently referring >> >> Â Â to a string. I may add another ivar "contentType" >> >> Â Â in the future to handle/distinguish additionaly types >> >> Â Â (HTML, SqueaksRichText, Morphs/BookMorph, ...) >> >> >> >> Â 5. HelpSystem should not be limited to Squeak. It should also >> >> Â Â serve the case that when you write and deploy a commercial >> >> Â Â app in Squeak you may use it to provide help to your >> >> Â Â end user/customer >> >> >> >> Â 6. There are two types of help I see: >> >> >> >> Â Â Â A. SystemHelp: Â Â Â Help books/Tutorials/Manuals >> >> Â Â Â B. SystemReference: API Help, class comments >> >> >> >> Â Â HelpSystem is supporting both. >> >> Â Â I already wrote about the differences and details in >> >> >> >> >> >> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html >> >> >> >> Â 7. I would really like to see support for HTML viewing >> >> Â Â in the image (HTMLViewMorph or so) - maybe based on Scamper >> >> Â Â to get a better viewer (headings, tables, ...) than the >> >> Â Â current plain text. >> >> Â Â If people want to contribute they should start right with this >> >> Â Â task. >> >> >> >> Â Â I know that Laurent already made Scamper loadable in Pharo, >> >> Â Â dont know about the state in Squeak. >> >> >> >> Â Â There is also another HTML browser with markup and CSS now >> >> available >> >> Â Â open source as MIT (WithStyle), I already mentioned this. >> >> >> >> >> >> >> >> http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&… >> >> >> >> Â 8. I know that we now have discussions on which syntax (Wiki,...) >> >> Â Â to use for describing the contents. >> >> Â Â My answer is: it is important but I dont care (yet) since >> >> Â Â this discussion is useless until we have an HTML viewer (see 7.) >> >> Â Â and Â even when there are different syntax styles you can provides >> >> Â Â builders to transform them into HTML or other contentTypes >> >> Â Â afterwards. >> >> >> >> Â Â See the class HelpBuilder and subclasses. >> >> >> >> Â 9. If you want to write a book for SystemHelp (see 6.A) then >> >> Â Â the help system provides a class "CustomHelp" similar >> >> Â Â to TestCase in SUnit. This class is used to directly >> >> Â Â map book structures to the class hierarchy. >> >> >> >> Â Â The intention was to be able to create, store and manage >> >> Â Â these books directly with the usual Smalltalk tools. >> >> Â Â You can even restructure your book with the RefactoringBrowser. >> >> >> >> Â 10. If you want to write API help you (see 6.B) can contribute >> >> Â Â right now by commenting all the undocumented classes in the >> >> Â Â standard image. >> >> >> >> Â Â HelpSystem just queries these informations from the usual >> >> Â Â sources (class comments, ...). I would not change this >> >> Â Â or make it too complicated since this is what people are >> >> Â Â used too. >> >> >> >> Â Â I dont see more documented classes by introducing a >> >> Â Â special syntax (wiki or whatever) people have to learn/know about >> >> Â Â - so lets clean up documenting the classes first. >> >> >> >> Â 11. HelpSystem is able to get contents from external sources >> >> Â Â (see the IRC example) - but I would prefer that authoring/viewing >> >> Â Â could be done right from within the image. >> >> Â Â Even when the result is stored external afterwards. >> >> >> >> Â Â Look at my example books: I can view and change them >> >> Â Â right from the image and make them available to other images >> >> Â Â using Metacello/Squeaksource. >> >> Â Â Accessibility of docu (viewing and authoring) is the key to keep >> >> Â Â the system and docu in sync and up to date. >> >> >> >> Â Â External authoring mostly results in unmaintained docu (see >> >> Â Â the Squeak Swiki). >> >> >> >> Â 12. I thought again if it is ready to integrate into Pharo and >> >> Â Â Squeak. From all the discussions I would say it is too early. >> >> >> >> Â 13. If one wants the docu on the web the answer is easy: we >> >> Â Â can generate static files or serve them with Seaside. >> >> Â Â But I have no need for that right now, especially since >> >> Â Â this is already available in various forms. >> >> >> >> We can do many things (similar to Python, JavaDoc, you name it) >> >> >> >> But - let's do it step by step. As I said: >> >> >> >> Â - Someone working on a good HTML Viewer that I can integrate >> >> Â would really help moving this forward >> >> Â (based on Scamper or by porting WithStyle) >> >> Â - Updating class comments would also help a lot >> >> >> >> Bye >> >> Torsten >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> >> >> _______________________________________________ >> >> 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 21, 2010

Re: [Pharo-project] [squeak-dev] Re: Talking to Steve Jobs about Scratch.

by Phil (list)

John & Stephane, Fair enough and good to know that folks like ESUG will be weighing in. I think you're on the right track re: gathering vocal support from the Scratch community that is constructive rather than bashing Apple, and have mainly been wondering why there wasn't a more concerted push from the Smalltalk and dynamic languages community in general talking about how policies like this would make iPhone OS a non-viable platform for them and push them to invest in alternatives such as Android to the exclusion of iPhone OS, rather than in addition to it. I'm not sure how much additional impact that would have, but the endgame for many tools/languages on iPhone OS doesn't seem to be very far off and I'm not terribly optimistic on how this will be decided. Thanks, Phil On Apr 21, 2010, at 4:48 PM, John M McIntosh wrote: > Phil, last week I asked the smalltalk community (ESUG etc), to stay > claim and wait for Apple to think about it based on an email > exchange I had with Steve Jobs. At the time I thought it prudent to > wait a further decision or statement. > > Give that Wired publish Alan & my thoughts on the matter it's likely > now time to consider what to do next. > > So this is NOT the fault of ESUG not being proactive, they were > itching to do something. > > At the moment I believe they are collecting ideas how to approach > the problem in a meaningful manner. > Suggestions are welcome. > > > On 2010-04-21, at 1:29 PM, Phil (list) wrote: > >> I've been surprised that I haven't seen any statement from ESUG re: >> how these policies negatively impact the future prospects for >> Smalltalk on the iPhone/iPad and the investments they've made in >> the platform to date that Apple seems willing to wipe out. >> Wouldn't now be a good time to try to get some visibility on the >> larger issue? >> >> Phil > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > >

April 21, 2010