- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI in 1.1

by Mariano Martinez Peck

On Wed, Apr 21, 2010 at 5:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/4/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Thu, Apr 15, 2010 at 9:31 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> Hi all > >> > >> Do we add FFI by default in 1.1? > > > > Noooooooooo!!! > > > > I wouldn't include neither FFI or Alien FFI in neither PharoCore or > PharoDev > > image. > > > > FFI is an EXTERNAL package, NOT core, neither a dev tool. > > > > Frankly, its a dev tool. What else it is if not a dev tool? > Just a library, but not a dev tool from my point of view. I understand from "dev tool" a tool aimed for make the developrs life better: good browsers, autocompletion, color hightitlying, refactoring tools, etc. > You have to be extremely careful, as with anything which using C or > binary interfaces, > but apart from it, i see nothing wrong with it. > How else you can easily bind an external API to image? Writing a plugin? > You could, but what the point in spending a lot of hours writing a > primitives for each > API function, when in the end, you still will be doing pretty same > thing: using external api? > > > That's only my opinion. > > > > Cheers > > > > Mariano > > > >> > >> This was the plan so. > >> > >> Stef > >> > >> _______________________________________________ > >> 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 > > > > > > -- > 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 25, 2010

Re: [Pharo-project] Serialization of font object

by Mariano Martinez Peck

On Fri, Apr 23, 2010 at 9:22 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 23, 2010, at 7:37 33PM, StÃ©phane Ducasse wrote: > > > may be using the storeOn: aStream and readFrom: mechanism? > > > I doubt it would work for FreeType fonts, which hold external handles. > mmmmm but do you want also to serialize external handles ? what are you going to do with them when you load the objects again to memory ? > For StrikeFonts, it may, but even if it did, you'd probably end up > importing a new Font instance (complete with an XX KB bitmap), for each > Morph... > > Cheers, > Henry > > > > > On Apr 23, 2010, at 4:28 PM, Henrik Johansen wrote: > > > >> On Apr 23, 2010, at 4:01 48PM, nullPointer wrote: > >> > >>> > >>> > >>> Regards > >>> > >>> I see in Pharo a few ways for create a font, StrikeFont, LogicalFont... > I > >>> need generate dinamically code in Smalltalk for build UIs, and my > problem > >>> now is when I have serialize the font of a widget. Which could be the > best > >>> way for do that? In other objects like arrays, points, associations is > >>> possible get that calling #printString method. Exists some equivalence > for > >>> that in fonts, or is needed implement that mechanism of zero? > >>> > >>> Thanks for answers > >> > >> I would store the the name/boldness/size etc., then use (LogicalFont > familyName: pointSize: stretchValue:weightValue: slantValue: ) realFont > >> to discover the closest font available when loading the morph into an > image again. > >> > >> Cheers, > >> Henry > >> _______________________________________________ > >> 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 25, 2010

[Pharo-project] #findString:startingAt:caseSensitive: broken

by Lukas Renggli

The method #findString:startingAt:caseSensitive: seems to be quite broken. This is sort of a critical bug, because the widely used #includesSubstring:caseSensitive: (in Pier and Seaside) depends on it. http://code.google.com/p/pharo/issues/detail?id=2353 First, the method #findString:startingAt:caseSensitive: has all kinds of strange comments and warning from a unfinished implementation. Furthermore -- and this is the bug I am encountering -- it replaces the string to be searched with an empty WideString if either the search or the searched string are WideString instances. Thus in the case any of the participating strings is a WideString the code never finds a match. WideString new findSubstring: key in: self startingAt: start matchTable: CaseInsensitiveOrder In addition, when used in combination with #includesSubstring:caseSensitive: the code raises a "subscript is out of bounds" exception, because the start index points to an different string than the empty one the search is actually performed on. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 25, 2010

Re: [Pharo-project] making O/Ecompletion even better

by StÃ©phane Ducasse

On Apr 25, 2010, at 3:55 PM, Tudor Girba wrote: > Hi Stef, > > No you are not :). > > I also mentioned once two more issues: > - Enter should not trigger completion because it interferes with code formatting. I would only keep tab as a means to trigger completion and to select something yes you are probably right. I was in favor of this inverse... but I learned :) > - right now, when pressing the down key because you saw a good completion item in the second position there is a visible delay because the ECompletion is triggered. ECompletion should either be integrated in the OCompletion directly, or should be triggered only when we hit the bottom of the three items. In the current form, having the completion item in the second position is almost as bad as not having it at all. > > Unfortunately, I do not have time to look into these issues, but I can offer testing :) romain :) please....... with the eye of the cat in shrek > > Cheers, > Doru > > > On 25 Apr 2010, at 15:45, StÃ©phane Ducasse wrote: > >> Hi romain >> >> Often when I edit code, the completion works well but I end up been forced to delete part of the text manually. >> Here is the scenario >> >> >> classDefinedSelector foo... >> ^ >> cursor >> >> Then I type meta >> >> the system proposes me metaclassDefinedSelector >> I type enter >> >> and I get >> >> metaclassDefinedSelector classDefinedSelector foo >> ^ >> >> so I have to remove by hand classDefinedSelector. >> >> So it would be good if we could eat the current text when doing the substitution. >> >> Am I the only one getting such behavior? >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

Re: [Pharo-project] making O/Ecompletion even better

by Tudor Girba

Hi Stef, No you are not :). I also mentioned once two more issues: - Enter should not trigger completion because it interferes with code formatting. I would only keep tab as a means to trigger completion and to select something - right now, when pressing the down key because you saw a good completion item in the second position there is a visible delay because the ECompletion is triggered. ECompletion should either be integrated in the OCompletion directly, or should be triggered only when we hit the bottom of the three items. In the current form, having the completion item in the second position is almost as bad as not having it at all. Unfortunately, I do not have time to look into these issues, but I can offer testing :) Cheers, Doru On 25 Apr 2010, at 15:45, StÃ©phane Ducasse wrote: > Hi romain > > Often when I edit code, the completion works well but I end up been > forced to delete part of the text manually. > Here is the scenario > > > classDefinedSelector foo... > ^ > cursor > > Then I type meta > > the system proposes me metaclassDefinedSelector > I type enter > > and I get > > metaclassDefinedSelector classDefinedSelector foo > ^ > > so I have to remove by hand classDefinedSelector. > > So it would be good if we could eat the current text when doing the > substitution. > > Am I the only one getting such behavior? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

April 25, 2010

Re: [Pharo-project] making O/Ecompletion even better

by Hilaire Fernandes

StÃ©phane Ducasse a Ã©crit : > > so I have to remove by hand classDefinedSelector. > > So it would be good if we could eat the current text when doing the substitution. > > Am I the only one getting such behavior? Yes, it makes sense. Otherwise I have to admit I found the completion pretty neat and smart in some part. I guess it does some statistick on the search terms because I get back quite quickly what I am looking for. Hilaire

April 25, 2010

[Pharo-project] making O/Ecompletion even better

by StÃ©phane Ducasse

Hi romain Often when I edit code, the completion works well but I end up been forced to delete part of the text manually. Here is the scenario classDefinedSelector foo... ^ cursor Then I type meta the system proposes me metaclassDefinedSelector I type enter and I get metaclassDefinedSelector classDefinedSelector foo ^ so I have to remove by hand classDefinedSelector. So it would be good if we could eat the current text when doing the substitution. Am I the only one getting such behavior? Stef

April 25, 2010

Re: [Pharo-project] Need your help filling a FAQ

by StÃ©phane Ducasse

super cool :) Questions: - does it work on mac, linux..? - how to enable it? - why did you choose ffi and not alien? - does it work on pharo? - what is the representation that you use to convert it to assembly? byteocde or ast if AST which one? RBAst? Stef On Apr 25, 2010, at 10:28 AM, Igor Stasenko wrote: > Hello guys, > > i'm currently writing a documentation for my project - NativeBoost. > > The work is based on a simple plugin which i wrote, which allows to > run a native code from Squeak. > The native code is attached to a compiled method itself (into its > trailer), and so lives within an image. > The plugin can run this code through a single primitive, which knows > how to do it right. > > Actually VM requires very small changes to support that. The bulk of > the work lies at the language side. > I'm currently working on making FFI callout support interface which > will support many cool things, comparing to usual FFIPlugin. :) > > I'd like to know, what details you want to know about it (tautology ;) > , so i will compose the FAQ along with other details about project. > > > P.S. Google became too smart :) Once i clicked 'send' button, its > shows a message box: > Did you mean to attach files? > You wrote "is attached" in your message, but there are no files > attached. Send anyway? > > -- > 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 25, 2010

Re: [Pharo-project] saving headless image on Mac

by Tudor Girba

Hi, Thanks for the info. On Linux, running the script headless works without problems. Only on Mac it produces strange behavior. Regarding the fix for the window size, I was looking for something that works with the -headless parameter :). Is there really no other solution? Cheers, Doru On 25 Apr 2010, at 07:47, Yanni Chiu wrote: > Tudor Girba wrote: >> Hi, >> I am trying to integrate a Pharo image into a continuous >> integration system through the command line. For that I need to >> spawn the image, do something, save and quit. >> The problem is that on Mac (using 4.2.2beta1U), when I open the >> resulting image I get a very tiny window instead of the original >> size. > > This has been bothering me for a long time, and Lukas' recent thread > on "Change Window Size" pushed me to take a look at it. I found > out, just like you, that just the save-and-quit would result in the > tiny window. > >> The command below reveals the problem (save-and-quite-image.st is >> attached): >> /Applications/Squeak4.2.2beta1U/Squeak\ 4.2.2beta1U.app/Contents/ >> MacOS/Squeak\ VM\ Opt -headless Pharo-1.0.image THE_PATH/save-and- >> quit-image.st >> Could anyone advise me how to proceed to get around this problem? > > Since you're on a Mac, could you add a final fix-up step that runs > the vm without the "-headless" option, sets the window size, then > runs save-and-quit. > > I added: > > HostWindowProxy basicNew primitiveWindowSize: 1 x: 1024 y: 786. > > before the save and quit code. I used another build.sh script that > skipped the "-headless" option, and ran the script. As expected, the > Pharo window popped up briefly. In the end, I finally have an image > that opens up with a reasonable size. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Speaking louder won't make the point worthier."

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by Igor Stasenko

On 25 April 2010 10:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/4/25 Igor Stasenko <siguctua(a)gmail.com>: >> imo, it should look like: >> >> readFrom: stream >> Â ^ readFrom: stream pattern: ISO8601 >> >> and >> readFrom:pattern: >> > > Yes, and next step will be to optimize with a pre-compiled pattern > (may use a cache). > Otherwise, when you have a bunch of String to convert in DateAndTime, > you're spending time in parsing the same pattern repeatedly. > Sure... piece of cake: ISO8601 := DateTimePattern compileFrom: 'xyz...[]./s]wefj..' And readFrom:pattern: could check that: compiledPattern := pattern isString ifFalse: [ pattern] ifTrue: [ DateTimePattern compileFrom: pattern ]. > Nicolas > >> should parse date by taking an arbitrary pattern into account. >> We could invent own syntax for a pattern, or use other invented ones >> (from C, Perl etc), >> and implement a separate DateTimeParser class. >> >> The messy code like this >> Â aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. >> Â Â Â year := (aStream upTo: $-) asInteger * bc. >> Â Â Â month := (aStream upTo: $-) asInteger ifNil: [1]. >> Â Â Â day := (aStream upTo: $T) asInteger ifNil: [1]. >> Â Â Â hour := (aStream upTo: $:) asInteger ifNil: [0]. >> >> should be put in trash! :) >> >> On 24 April 2010 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >>> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >>> >>> Stef >>> >>> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >>> >>>> 2010/4/24 Julian Fitzell <jfitzell(a)gmail.com>: >>>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>>> <stephane.ducasse(a)free.fr> wrote: >>>>>> >>>>>> What are the expectation for DateAndTime>>readFrom? >>>>> >>>>> Personally, my expectation is that it doesn't exist. :) >>>>> >>>>> To believe that there is a single way of parsing strings into dates (or >>>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>>> silly. It would seem much better to me to have configurable parsing classes. >>>>> >>>>> Julian >>>>> >>>> >>>> Sure, that might be usefull, however current implementation intention >>>> clearly seems related to >>>> http://en.wikipedia.org/wiki/ISO_8601 >>>> >>>> Nicolas >>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> 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 > > _______________________________________________ > 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 25, 2010