- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Canvas transform bug when rendering text?

by StÃ©phane Ducasse

thanks! PS: I will integrate some other fixes when back to the garage later today.... Got stuck on the highway without gaz :) ... yesterday. >>> > > David, Lukas, whomever else it may concern. > > Of course I turned out to be (partly) wrong when looking into it. > Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating... > Try the attached code, and you should get better results. (you probably want to use smoothing > 1 if displaying text with rotation other than a multiple of 90 degrees). > > This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window) > > Cheers, > Henry > <FormCanvas-transformByclippingToduringsmoothing.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 9, 2010

Re: [Pharo-project] [Preview] Help System with new model

by StÃ©phane Ducasse

yes this was my gut feeling too. What I like with method annotation is that we can get people writing executable examples. Once I discussed with lukas about tests and to me there is a difference between writing tests for coverage and for public consumption. For public consumption you write meaningful api sequence, mini scenario. Stef On Apr 8, 2010, at 11:49 PM, Michael Roberts wrote: > Torsten, i appreciate the thought you are putting in. I just wonder if > the definition of the help (the raw content) should also be bound up > with the definition of the overall structure? I also wonder if I want > to bend the help system in a way that it is not intended. > > For me i want something that is like python doc strings, and the great > python package documentation available, ... but in a more smalltalk > in-image manner. So that's why i think of it in terms of annotations. > Having the help be in its own help class, on the class side, without > any real behavior is a design smell to me. I don't really like heavy > class-side programming; the class doesn't really offer any behaviour > or scale across the image. I guess i want to see docs spread across > the system. you want them central? to me the classes are really just > annotations, apart from as you say needing to provide the role of > structure for the nested content. > > my use case is that the documentation must be next to the code it is > documenting. the network package is a good example. Since the API is > in a state of flux, and no one knew how the 'new' api was supposed to > work, it could really benefit detailed documentation for each version > of pharo. it will change likely for each major version. the docs need > to be in the package. fine, we can have the requisite 2 classes > already in the image. that is ok. but it would be better to have the > doc content on the actual system classes themselves. Like > NetNameResolver. and Socket, etc. so i either have to have my custom > class reference them, in some imperative manner, or i need to build a > builder.. or something. I had imagined it would be possible to have > standard places/hooks for packages and classes, where annotations > would go. for example like stef says we could pull out the class > comment. > > also, i imagine if documenting the system, in a system wide manner, > was successful we would have lots of doit expressions. some mashup > between workspaces, profstef, and hypertext. in that case it would be > nice to somehow link doc expressions that are really little test > assertions together, so we can actually test the docs to make sure > that they validate against the system code. I think the SBE/PBE latex > sources had this idea in them. And Adrian K has posted examples of > these nice extensions to sunit that read very well. I would like that > feeling somehow integrated, otherwise we won't be able to maintain the > sanity of our docs either. so i guess i'm kinda with stef's comments > later in this thread. > > but anyway, we start with zero in-image documentation. for me we must > just have a doc system that scales. i really want to see the docs in > the packages, not in a single central package. we'll just have to see > how it plays out. i don't want to take away from building a 'help > system' that would let you provide F1 style help for an actual > application - we just desperately need system level documentation to > take Pharo to the next level. I guess I see no need for defining > inter-help structure because I think for system level docs it can be > entirely derived. each package, class, method can all be annotated in > a consistent manner. programming examples could be attached to > classes in a standard manner. you could then provide a browser giving > A-Z, hierarchy, package, classes, search, index, etc views on these > annotations. This is not what you are trying to do with your help > system, but i see this as a subset of the intent and a lot of the > logic already there. i'm not sure if i'm making any sense... > > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 9, 2010

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

by Lukas Renggli

> * Single/multi-line popups - when you're extracting a method via "refactor > source," you get a huge multi-line popup window, which eats crs, so after > you enter the name and hit return, you are still in the popup and must take > your hands off the keyboard to click "ok." It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names? > Now, fair enough, this might > actually be a good thing in other circumstances, but - when you reference an > unknown class, you get an "unknown variable" popup, choose "define new > class," click through the category selection, you get a one-line popup to > edit a paragraph-long class definition, lol! Â So: > Â - "refactor source->extract method" should be a single-line popup > Â - and, "define new class->edit class definition" should be a multi-liner. I 100% agree on this, class definition from within the editor totally sucks. Unfortunately this is part of the compiler, not the browser so it requires a change to the parser. I propose the fix below, that also avoids the extra question of asking for the category name. This is unnecessary as it can be edited afterwards in the class definition anyway. http://code.google.com/p/pharo/issues/detail?id=2286 Name: Compiler-LukasRenggli.208 Author: lr Time: 9 April 2010, 8:23:45 am UUID: e0f99e58-08ce-46da-839d-88947b66d668 Ancestors: Compiler-StephaneDucasse.207 - simplify and improve the user experience for class definition while compiling a method Lukas -- Lukas Renggli www.lukas-renggli.ch

April 9, 2010

[Pharo-project] Initial experience coming from Squeak

by Sean P. DeNigris

I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with. And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing "good ideas" i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute? Suggestions: * Why shift for meta? On a Macbook (with one button), it's awkward to press shift+alt+click, and also disorienting to go back and forth from Squeak which is just alt+click. Is there a reason to not keep the convention? * what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manuallyâ¦ Certainly not a big deal, but weird. I though of a few possible fixes: - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click) * bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow. * new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is. * Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok." Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an "unknown variable" popup, choose "define new class," click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - "refactor source->extract method" should be a single-line popup - and, "define new class->edit class definition" should be a multi-liner. Thanks for an awesome environment, and I will continue to contribute any way I can :) Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p179904… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 9, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Henrik Sperre Johansen

On 07.04.2010 14:26, Henrik Johansen wrote: > > On Apr 7, 2010, at 1:45 49PM, David Harvey wrote: > >> Hi list, >> >> I'm writing a little charting morph, and while playing with rotating >> text for axis labels came across something which I've noted in Morphs >> text handling a couple of times. >> >> If I apply a transform in a drawing operation, rotated text _appears_ >> to be drawn twice, slightly offset, giving a scrappy bold look. It >> seems only to do this when drawing on a form canvas that's backed >> onto the display: if you pick and drag the morph, the text is >> rendered beautifully. >> >> The test morph attached isolates the problem. The transcript logging >> is an attempt to see what might be happening: looking at the output >> it appears that there are circumstances in which the during: block is >> invoked twice. >> >> Any thoughts? >> >> David > > http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a16918… > > Basically, transform doesn't work with depth 32. > Workarounds are described in the thread. > > Cheers, > Henry David, Lukas, whomever else it may concern. Of course I turned out to be (partly) wrong when looking into it. Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating... Try the attached code, and you should get better results. (you probably want to use smoothing > 1 if displaying text with rotation other than a multiple of 90 degrees). This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window) Cheers, Henry

April 9, 2010

Re: [Pharo-project] Linux vm: assertions and strategy

by Schwab,Wilhelm K

Laurent, The promised code for tryLoadModule(); it goes just before if (!handle) { struct stat buf; if ((0 == stat(path, &buf)) && ! S_ISDIR(buf.st_mode)) fprintf(stderr, "%s\n", dlerror()); } return handle; Drop the fprintf() calls if you want - I know what was happening now? Bill ======================== /* wks - have not loaded a library? Is the path absolute? Use the name as given. */ if( (!handle) && ( (int)(name[0])==47 ) ) { handle=dlopen(name, RTLD_NOW | RTLD_GLOBAL); fprintf(stdout,"WKS-load-by-name(%s) = %p\n", path,handle); } else { if(!handle){ fprintf(stdout,"WKS-refuse-load-by-name(%s) - not absolute path\n", path); } } ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Thursday, April 08, 2010 6:10 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Linux vm: assertions and strategy Laurent, A part-time boss/full-time friend once advised me to "get the machine to tell you what it's doing" (I was doing just that at the time, but I've never forgotten his advise<g>). I compiled your vm and then decided to stick some tracing code in strategic places to find what the vm thinks it is doing in trying to load unixODBC. Get ready: tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) = (nil) In short, it does not appear to recognize a difference between plugins (the names of which it twists around to avoid collisions with external libraries - that's fine) and external libraries that have been minding their own business for many clock cycles. The latter deserve special attention. So I had an absolutely nutty idea: give dlopen() the name of the library as written :) Clearly, that works only if one provides an absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome here) that is easy to test and even easier to do in the code. So, in sqUnixExternalPrims.c in the unix/vm directory, look near the end of tryLoadModule(). My proposed workaround is to add some code before the !handle test at the end. I will send a cut-down version of it in a separate email. Unless someone has a better idea, I suggest we make this change to you source to give people an opportunity to use external libraries: (1) I fear at all(!!); (2) by absolute path if desired. BTW, the 3.11-3 vm indeed appears to have fixed my problem w/ double return values, at least the boiled-down test works. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Thursday, April 08, 2010 3:22 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Linux vm: assertions and strategy 2010/4/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> Laurent, I was reading a little about Eliot's proposed FPU init changes to FFI and then took another look at your evolving Pharo vm source and I was struck by either: (1) a brilliant (well, fairly clever) workaround to my external library hassles; (2) a completely and totally stupid idea. You have based the vm on the 3.11-3 sources, so it hopefully fixes the double return defect that has been driving me nuts. My remaining problem is to get the vm to load external libraries. Would a simple plugin to expose dlopen() (and perhaps dlsym() while we're at it) solve the problem? I should then be able to bypass the FFI code that calls dlopen() (I suspect that it's pretty badly broken) by setting the handle of any ailing library by using absolute paths if necessary. From there, I *think* everything will just work. What do you think? Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :) So I cannot tell anything...I have to learn before. Somewhat related, have you looked at compiling the Alien plugin? The more I look at posts on Alien, the more I wonder whether it will help, as there are suggestions that it is weak on external calls. Still, it would be nice to get it going and look over the tests the boldness that comes from watching them pass having actually done something. Yes I can compile it, but the VM crashes loudly when trying to use it. This thread has a lot of informations: http://n4.nabble.com/Trying-to-build-alien-plugin-in-linux-tc1562896.html Laurent Laffont Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of laurent laffont Sent: Thursday, April 08, 2010 7:32 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Linux vm: assertions and strategy I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate ? It seems there's actually some problems with it http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi On my machine, 20/21 FFI unit tests fails... I haven't been able to build last revision of squeak-vm trunk. Laurent Laffont On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Laurent, all, If I may jump to conclusions a little, the 3.11-3 vm's changes break the loading of libraries, certainly to the point of being arkane. Beyond that, LinuxODBC is transparent to it, so I am left wondering how it is suppose to work at all?? The RC3 one-click image and vm produce very nice fonts on my Ubuntu laptop, but it retains the FFI/double defect, and from the naming of the plugins, must be based on a pre 3.11-3 vm. Is the plan to use 3.11-3 for the one-click? If so, we need to do something about external libraries; at a minimum, LinuxODBC should work, whether by fully understanding how to use environment variables, or (as I suspect) getting the dlopen() call to work again. Another option is to identify the FPU related fixes and apply them to the current one-click vm. Any preferences? Any success with 3.11-3 and LinuxODBC? I'd be happy to be wrong about this. Bill _______________________________________________ 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 _______________________________________________ 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

April 9, 2010

Re: [Pharo-project] Linux vm: assertions and strategy

by Schwab,Wilhelm K

Laurent, A part-time boss/full-time friend once advised me to "get the machine to tell you what it's doing" (I was doing just that at the time, but I've never forgotten his advise<g>). I compiled your vm and then decided to stick some tracing code in strategic places to find what the vm thinks it is doing in trying to load unixODBC. Get ready: tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) = (nil) In short, it does not appear to recognize a difference between plugins (the names of which it twists around to avoid collisions with external libraries - that's fine) and external libraries that have been minding their own business for many clock cycles. The latter deserve special attention. So I had an absolutely nutty idea: give dlopen() the name of the library as written :) Clearly, that works only if one provides an absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome here) that is easy to test and even easier to do in the code. So, in sqUnixExternalPrims.c in the unix/vm directory, look near the end of tryLoadModule(). My proposed workaround is to add some code before the !handle test at the end. I will send a cut-down version of it in a separate email. Unless someone has a better idea, I suggest we make this change to you source to give people an opportunity to use external libraries: (1) I fear at all(!!); (2) by absolute path if desired. BTW, the 3.11-3 vm indeed appears to have fixed my problem w/ double return values, at least the boiled-down test works. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Thursday, April 08, 2010 3:22 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Linux vm: assertions and strategy 2010/4/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> Laurent, I was reading a little about Eliot's proposed FPU init changes to FFI and then took another look at your evolving Pharo vm source and I was struck by either: (1) a brilliant (well, fairly clever) workaround to my external library hassles; (2) a completely and totally stupid idea. You have based the vm on the 3.11-3 sources, so it hopefully fixes the double return defect that has been driving me nuts. My remaining problem is to get the vm to load external libraries. Would a simple plugin to expose dlopen() (and perhaps dlsym() while we're at it) solve the problem? I should then be able to bypass the FFI code that calls dlopen() (I suspect that it's pretty badly broken) by setting the handle of any ailing library by using absolute paths if necessary. From there, I *think* everything will just work. What do you think? Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :) So I cannot tell anything...I have to learn before. Somewhat related, have you looked at compiling the Alien plugin? The more I look at posts on Alien, the more I wonder whether it will help, as there are suggestions that it is weak on external calls. Still, it would be nice to get it going and look over the tests the boldness that comes from watching them pass having actually done something. Yes I can compile it, but the VM crashes loudly when trying to use it. This thread has a lot of informations: http://n4.nabble.com/Trying-to-build-alien-plugin-in-linux-tc1562896.html Laurent Laffont Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of laurent laffont Sent: Thursday, April 08, 2010 7:32 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Linux vm: assertions and strategy I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate ? It seems there's actually some problems with it http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi On my machine, 20/21 FFI unit tests fails... I haven't been able to build last revision of squeak-vm trunk. Laurent Laffont On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Laurent, all, If I may jump to conclusions a little, the 3.11-3 vm's changes break the loading of libraries, certainly to the point of being arkane. Beyond that, LinuxODBC is transparent to it, so I am left wondering how it is suppose to work at all?? The RC3 one-click image and vm produce very nice fonts on my Ubuntu laptop, but it retains the FFI/double defect, and from the naming of the plugins, must be based on a pre 3.11-3 vm. Is the plan to use 3.11-3 for the one-click? If so, we need to do something about external libraries; at a minimum, LinuxODBC should work, whether by fully understanding how to use environment variables, or (as I suspect) getting the dlopen() call to work again. Another option is to identify the FPU related fixes and apply them to the current one-click vm. Any preferences? Any success with 3.11-3 and LinuxODBC? I'd be happy to be wrong about this. Bill _______________________________________________ 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 _______________________________________________ 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

April 9, 2010

Re: [Pharo-project] [Preview] Help System with new model

by Michael Roberts

Torsten, i appreciate the thought you are putting in. I just wonder if the definition of the help (the raw content) should also be bound up with the definition of the overall structure? I also wonder if I want to bend the help system in a way that it is not intended. For me i want something that is like python doc strings, and the great python package documentation available, ... but in a more smalltalk in-image manner. So that's why i think of it in terms of annotations. Having the help be in its own help class, on the class side, without any real behavior is a design smell to me. I don't really like heavy class-side programming; the class doesn't really offer any behaviour or scale across the image. I guess i want to see docs spread across the system. you want them central? to me the classes are really just annotations, apart from as you say needing to provide the role of structure for the nested content. my use case is that the documentation must be next to the code it is documenting. the network package is a good example. Since the API is in a state of flux, and no one knew how the 'new' api was supposed to work, it could really benefit detailed documentation for each version of pharo. it will change likely for each major version. the docs need to be in the package. fine, we can have the requisite 2 classes already in the image. that is ok. but it would be better to have the doc content on the actual system classes themselves. Like NetNameResolver. and Socket, etc. so i either have to have my custom class reference them, in some imperative manner, or i need to build a builder.. or something. I had imagined it would be possible to have standard places/hooks for packages and classes, where annotations would go. for example like stef says we could pull out the class comment. also, i imagine if documenting the system, in a system wide manner, was successful we would have lots of doit expressions. some mashup between workspaces, profstef, and hypertext. in that case it would be nice to somehow link doc expressions that are really little test assertions together, so we can actually test the docs to make sure that they validate against the system code. I think the SBE/PBE latex sources had this idea in them. And Adrian K has posted examples of these nice extensions to sunit that read very well. I would like that feeling somehow integrated, otherwise we won't be able to maintain the sanity of our docs either. so i guess i'm kinda with stef's comments later in this thread. but anyway, we start with zero in-image documentation. for me we must just have a doc system that scales. i really want to see the docs in the packages, not in a single central package. we'll just have to see how it plays out. i don't want to take away from building a 'help system' that would let you provide F1 style help for an actual application - we just desperately need system level documentation to take Pharo to the next level. I guess I see no need for defining inter-help structure because I think for system level docs it can be entirely derived. each package, class, method can all be annotated in a consistent manner. programming examples could be attached to classes in a standard manner. you could then provide a browser giving A-Z, hierarchy, package, classes, search, index, etc views on these annotations. This is not what you are trying to do with your help system, but i see this as a subset of the intent and a lot of the logic already there. i'm not sure if i'm making any sense... cheers, Mike

April 8, 2010

[Pharo-project] iPhone OS 4 SDK, section 3.3.1

by Sean Malloy

The old version: 3.3.1 â Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. The new version: 3.3.1 â Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). Anyone have any thoughts on this change to the agreement?

April 8, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by StÃ©phane Ducasse

great this one was annoying too :) On Apr 8, 2010, at 11:16 PM, Romain Robbes wrote: > I also published, in Ocompletion-RomainRobbes.55, a potential fix for this issue: > > http://code.google.com/p/pharo/issues/detail?id=1678 > > Cheers, > Romain > > On Apr 8, 2010, at 4:55 PM, StÃ©phane Ducasse wrote: > >> >> On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote: >> >>> Dear list, >>> >>> I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. >> >> Excellent! >> >>> The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. >>> To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. >>> >>> You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). >> >> I'm sure that people will give you feedback. >> >>> >>> Cheers, >>> Romain >>> >>> -- >>> Romain Robbes >>> http://romain.robb.es >>> rrobbes(a)dcc.uchile.cl >>> >>> >>> _______________________________________________ >>> 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 > > -- > Romain Robbes > http://romain.robb.es > rrobbes(a)dcc.uchile.cl > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2010