Squeak-dev April 2010

squeak-dev@lists.squeakfoundation.org

122 participants
595 discussions

[Documentation] What about package comments?
by Hannes Hirzel 13 Sep '10

13 Sep '10

Hello I found the proposal by Bernhard Pieber and Ralph Johnson to introduce package comments? It was in the thread HttpView2 where I think some people interested in documentation will miss it. An application could be to automatically generate documentation, i.e. for example at Squeaksource. --Hannes >From the HttpView2 thread On 4/23/10, Ralph Johnson <johnson(a)cs.uiuc.edu> wrote: > On Fri, Apr 23, 2010 at 5:39 AM, Bernhard Pieber <bernhard(a)pieber.com>wrote: > >> - IMHO, there should be first class package comments along the lines of >> class and method comments, i.e. version controlled in PackageInfo. This >> would greatly improve the Monticello browser. And SqueakSource could use >> them as project descriptions. (I once argued [1] that the easiest >> implementation of this would be a PackageInfo subclass for each package. >> Its >> class comment would be the package comment. Pre and post load code could >> be >> put there as well. You could reuse all the development tools like that.) >> >> [1] >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088181… >> >> > This seems like a good idea. What tools would have to change to make this > work, and could we make this change backwards compatible? For example, if > you move the preload and postload code to the PackageInfo subclass then you > could leave forwarding code behind. Tools wouldn't bother displaying the > forwarding code if they saw the PackageInfo subclass, but would keep it so > that older versions of the tools would still work. > > -Ralph >

10 19

Documentation Team
by Casey Ransberger 25 Aug '10

25 Aug '10

Looking at http://squeak.org/Community/Teams/ I don't see a documentation team listed. Has it been disbanded? If the documentation team has been disbanded, I would like to offer to lead a new documentation team (in which case I would draft up a proposal with expected deliverables, etc.) If the documentation team has not been disbanded, I would like to join it.

7 16

Talking to Steve Jobs about Scratch.
by John M McIntosh 11 Jun '10

11 Jun '10

Let me give everyone an update on what is going on with Scratch.app, I've seen lots of discussion and speculation flow by on the esug, scratch and pharo lists, some of it correct, and some of it incorrect. First, Scratch.app was remove from sale in the app store because the Scratch programming language is an interpreted language, and it's not on the approved interpreted language list. My understanding is that Apple has not yet rejected apps because they are "made" with a particular language. The rejection is solely due to the result of Scratch being a non approved 'interpreted" language. Second, I drafted a letter titled: "Rejecting an app with foundations in the Dynabook vision" and posted it to: https://devforums.apple.com/thread/46425 At this time, this letter is not for public viewing since I want to have more discussion with Apple and the paid Apple developer community. It seems having public rage about the unfairness about what Apple is doing just makes Apple less receptive to dialog. I would ask the community not to cross post my letter anywhere until we have had more discussions with Apple. As an example this morning there was talk with a member of the App review team about having this matter ending up on Phil Shiller's desk. Third, I sent a copy of the letter to Steve Jobs. He did respond. Our incomplete conversation is private, no solution or decision has been reached, and due to Apple's earnings reports coming up next tuesday I don't foresee any activity on the matter until after that event. Fourth, I have interest & support from Dr Alan Kay, Dr Mitchel Resnick, and others, I think people do take the matter about the freedom to write applications in a language of their choosing and using a particular implementation (interpreted, JIT, compiled) seriously, so I hope movement with Apple on the general topic will occur shortly. Once Apple's management team has made a response I'm sure you will all hear about it. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

31 65

OpenCL bindings for Squeak
by Josh Gargus 07 Jun '10

07 Jun '10

For the last month or so, I've been working on some OpenCL bindings for Squeak. I now have something that's worth showing to people. The code is on Squeak source at: http://www.squeaksource.com/OpenCL.html and some rudimentary installation and usage documentation is at: https://sites.google.com/site/schwaj/home/opencl-binding-for-squeak I'll write more over the weekend (hopefully in response to questions and comments), but now it's time for bed. Cheers, Josh

5 12

[ANN] Maui 1.2 release 1
by Chris Muller 07 Jun '10

07 Jun '10

In conjunction with the release of Squeak 4.1, I have made a new release of Maui that works with 4.1 and will be supported on that platform going forward. Maui is a user-interface builder for Squeak with a goal of _quickly_ producing effective drag-and-drop user-interfaces without having to write any code (although interfaces are also easily created via code). When used in conjunction with MaSarPackage (to announced shortly), applications can be easily deployed to SqueakMap that include the designers Maui-based user-interface. Maui is the framework I use exclusively for internal UI's at my company. Obviously I like it because I designed it to conform to my principles of an effective UI. However, a naked-objects type of user-interface will not be suitable for many situations or tastes. My teammates seem to be liking it, although they are polite. Nonetheless, it can be quite useful to have in the image for "quick and dirty" but useful image tools that just aren't easy to do any other way.. To use, in a standard Squeak 4.1 image, open SqueakMap, find Maui, install "1.2r1". To build a UI immediately, try dragging "Association" out of the browser onto the desktop. That's the Association class on the desktop, so drag the *class-side* constructor, #key:value: onto it... Your first Maui UI. I would have liked, of course, to release this with a bunch of "content" to entertain you. But given my large agenda, short resources, and the relatively low response to 1.1, I would like to try to get more mileage out of the original pdf document available on the swiki, into which I did put quite a bit of work into explaining Maui. Comments or questions about this 1.2 are very welcome. - Chris

4 6

Trying to load ALienOpenGL into 4.1 alpha...
by Lawson English 28 May '10

28 May '10

hi all, was trying to load AlienOpenGL into 4.1 alpha and got the warning: This package depends on the following classes: AlienLibrary Is this deprecated for 4.x or renamed or..? Thanks, Lawson

10 43

Condensing sources in 4.1
by Andreas Raab 19 May '10

19 May '10

Hi - I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e, SqueakV41.source = SqueakV4.sources + Squeak4.1.changes This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired. What do people think? Sounds like a plan? Cheers, - Andreas

7 12

Re: [Pharo-project] Talking to Steve Jobs about Scratch.
by John M McIntosh 18 May '10

18 May '10

On 2010-04-22, at 6:22 AM, Stéphane Ducasse wrote: > I still naively believe that if all the programmers of the dynamic language put a logo with apple and a black skull on their > web page. Apple will get a bad press. Yes well I don't think that will achieve much. Personally I think that the people here involved in the education & university domains need to write actual paper based letters on their institution's letter head and mail them to the Apple education reps for their countries stating their concern about Apple's legal agreements that appear to lockout the iPad for extraordinary use in the computer science curriculum. This involves passionately arguing for the ability to program, or teach in something other than C, C++, Obj-C or Javascript, I"m sure others are more capable than me in composing that, as a software engineer my words aren't worth much, but I think computer science departments should be voicing their concern on the direction where things appear to be going. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

5 6

Alien & Squeak FFI issues on Snow Leopard.
by John M McIntosh 16 May '10

16 May '10

Someone finally managed to fire up a Sophie app http://www.opensophie.org/ on Snow Leopard and immediately found an issue that also affects Squeak users who do fascinating things with FFI The innocent FFI call was apifstat: afileNo statBuffer: buffer <cdecl: long 'fstat' (long MacStat* ) module: 'libc.dylib'> ^self externalCallFailed Now it seems BEFORE Snow Leopard *somehow* the Squeak external primitive call api which is part of the VM to assist in loading plugins or finding function entry points in executable binaries or libraries would return the entry point for fstat by *somehow* finding libc.dylib which is via /usr/lib/libc.dylib -> libSystem.dylib -> libSystem.B.dylib Interestingly this is found implicitly since the mac carbon vm lookup logic never looks in /usr/lib/ Now in Snow Leopard it seems they do less implicit searching, perhaps a security concern? Then it fails. In the past the Unix VM would search a hundred(sic) more places, but I understand less today, but it might still work? Maybe /usr/lib is in the hit list? This issue also applies to Alien because it calls back to the VM for it to find the module and function entry point. Since I have received a request to ensure that doing an explicit full path should be allowed in the squeak carbon macintosh vm. Then a change would be: apifstat: afileNo statBuffer: buffer <cdecl: long 'fstat' (long MacStat* ) module: '/usr/lib/libc.dylib'> ^self externalCallFailed I'll look at doing this shortly. However the workaround is to go to Sophie.app/Contents/Resources and do a ln -s /usr/lib/libc.dylib libc.dylib to create a symbolic link in the Resources directory for libc.dylib since we do explicitly look for libc.dylib in the Resources directory. Obviously if you have a FFI call like above where you are calling a system library Oracle? for example. You might find it no longer works with Snow Leopard on the Macintosh, so you should check. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

4 5

Re: [Pharo-project] [squeak-dev] Re: Menu Registries
by Alain Plantec 14 May '10

14 May '10

Andreas Raab a écrit : > On 4/28/2010 11:32 PM, Stéphane Ducasse wrote: >> Good but what is your point? > > Compatibility and simplicity. Come on Andreas, "simple" is not so much more precise than "cool" and I don't think that having: ------------------ Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ] EditorSetting class>>editorSettingsOn: aBuilder <systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' ------------------- is so much more "complicated" than ------------------- Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ] ------------------- You prefer UI+domain mixing, we prefer UI separated from domain. And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ... Cheers Alain

3 2

Jump to page: