November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New pharo-dev based on 10178

by Gary Chambers

For Linux you might want font paths (plural)... Regards, Gary. ----- Original Message ----- From: Andrew Tween To: pharo-project(a)lists.gforge.inria.fr Sent: Friday, November 28, 2008 12:15 PM Subject: RE: [Pharo-project] New pharo-dev based on 10178 > Date: Fri, 28 Nov 2008 14:06:44 +0200 > From: siguctua(a)gmail.com > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] New pharo-dev based on 10178 > > 2008/11/28 Andrew Tween <amtween(a)hotmail.com>: > > > > > >> Date: Fri, 28 Nov 2008 13:07:57 +0200 > >> From: siguctua(a)gmail.com > >> To: pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] New pharo-dev based on 10178 > >> > >> 2008/11/28 Andrew Tween <amtween(a)hotmail.com>: > >> > > >> > > >> > > >> >> Date: Fri, 28 Nov 2008 12:36:14 +0200 > >> >> From: siguctua(a)gmail.com > >> >> To: pharo-project(a)lists.gforge.inria.fr > >> >> Subject: Re: [Pharo-project] New pharo-dev based on 10178 > >> >> > >> >> 2008/11/28 Andrew Tween <amtween(a)hotmail.com>: > >> >> > > >> >> > If FFI is present, then FreeTypeFontProvider gets the windows font > >> >> > folder > >> >> > path with an API call. > >> >> > see FreeTypeFontProvider>>getWindowsFontFolderPath > >> >> > > >> >> > If FFI is not present, then > >> >> > FreeTypeFontProvider>>guessWindowsFontFolderPath > >> >> > is executed, which attempts to guess the fonts folder location. > >> >> > To do this it checks to see if c:\windows\fonts, d:\windows\fonts, > >> >> > e:\windows\fonts, etc. exist. > >> >> > > >> >> > >> >> use > >> >> SHGetSpecialFolderPath ( NULL, buffer , 0x14 /* = CSIDL_FONTS , from > >> >> <shlobj.h> */ , false) > >> >> of shell32.dll to retrieve the location of fonts directory in windoze. > >> >> > >> >> Then you don't need to guess anymore where windoze fonts located :) > >> > > >> > I obviously didn't make myself clear, so I'll have another go :) > >> > > >> > The guessing only happens if FFI is not present. > >> > > >> > If FFI is present then it uses FFI to call SHGetFolderPathA in > >> > shfolder.dll > >> > to get the location. > >> > > >> > please refer to FreeTypeFontProvider>>getWindowsFontFolderPath for the > >> > details. > >> > >> Aha. It not works, because there is no FFI package loaded into dev image. > >> Once i loaded FFI it stopped bugging me about inserting disk in a drive. > >> > >> May i guess, that dev image should contain FFI package by default? > > > > I would vote for including FFI in the dev image. > > And Alien, when it's ready. > > > >> > >> > > >> > SHGetSpecialFolderPath (or SHGetFolderPath) could be added to some > >> > plugin, > >> > rather than using FFI, but hasn't yet. > >> > > >> > >> s/some plugin/freetype plugin > >> > >> :) > > > > Or make it a general purpose thing in the VM > > > > i don't think that font path is too general to be in VM. True, but I was thinking beyond just the font path. Getting the Temp folder path, would also be useful. A general purpose function could do it all. e.g. getOSPath: 'fonts' getOSPath: 'temp' I seem to recall that that this has been discussed in the past on the squeak-dev list. > > >> > > -- > 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 ------------------------------------------------------------------------------ Read amazing stories to your kids on Messenger Try it Now! ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2008

Re: [Pharo-project] [ANN] prebuilt image #10178

by Gary Chambers

----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, November 27, 2008 11:28 PM Subject: Re: [Pharo-project] [ANN] prebuilt image #10178 > 2008/11/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Yeap it is really cool >> >>>> >>>> Additionally some might like showTextEditingState enabled, not me >>>> though! >>> >>> I need this one, else I always get confused because I forget to save >>> methods >>> Preferences enable: #showTextEditingState >> >> Me too all the time. :) > > I don't like that 'editor modified' state shown by drawing a red(or > another) border around morph's frame, because it is non-intuitive. > As to me it would be much better to show 2 tiny buttons in a corner of > morph with accept/cancel actions. > Indeed, the option is there for all those who complained when it was missing! Our browsers show "Modified" in the title bar... >> >>> >>> >>> These are the other preferences from above: >>> >>> Preferences enable: #alternativeButtonsInScrollBars. >>> Preferences disable: #alwaysShowVScrollbar. >>> Preferences disable: #scrollBarsNarrow. >>> Preferences enable: #scrollBarsWithoutMenuButton. >>> Preferences enable: #mouseClickForKeyboardFocus. >>> Preferences disable: #fadedBackgroundWindows. >>> Preferences disable: #fastDragWindowForMorphic. >>> Preferences disable: #fullScreenLeavesDeskMargins. >>> Preferences disable: #showSplitterHandles. >>> Preferences enable: #generalizedYellowButtonMenu >>> Preferences enable: #showTextEditingState >>> >>> Furthermore, I vote for: >>> Preferences enable: #noWindowAnimationForClosing >>> Preferences disable: #windowAnimation >>> Preferences setPreference: #GlyphContrast toValue: 55 >>> >>> I really like the Watery 2 look (the style of the buttons could be >>> improved, though). >>> >>> Cheers, >>> Adrian >>> >>>> >>>> >>>> Regards, Gary. >>>> >>>> ----- Original Message ----- From: "Marcus Denker" >>>> <denker(a)iam.unibe.ch> >>>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Thursday, November 27, 2008 3:38 PM >>>> Subject: [Pharo-project] [ANN] prebuilt image #10178 >>>> >>>> >>>>> https://gforge.inria.fr/frs/download.php/11844/Pharo0.1Core-10178.zip >>>>> -- >>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>> http://www.iam.unibe.ch/~denker >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > 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 >

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Igor Stasenko

2008/11/30 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> >> and besides: >> VMs is packaged with FFI as dynamic library. >> So, if you want extra safety - simply don't shipp your application >> with this DLL. >> >> But still, if you allow arbitrary code to run in your image, then what >> prevents script kiddie from doing following: > > the sandbox does that as it prevents writing of files in "interesting" > locations like the VM directory. > what if i put .dll in directory which is included in a search path? There can be many indirect ways to leave something on disk, and then run it by OS. Not sure about macs, but on windows, a good sandboxing would be to prevent any file i/o. But then if you running a seaside (or any mid-sized app), i'm sure you will need file i/o for yourself . > I'm all for using FFI/Alien, what I really tried to make people aware of is > that by using FFI instead of plugins certain things become more dangerous. > For standalone and server applications not loading any code from the outside > this is not a problem at all. > > By using FFI we need to more aware though that we potentially open up a > Squeak application to buffer overflow attacks, something that wasn't really > possible before. > > So I didn't want to put any brakes on, but raise people's awareness about > security. It's a bit like with the Mac: just because hackers haven't really > cared about exploiting vulnerabilities doesn't mean the Mac is safe. And we > Smalltalkers have considered us to use the Mac of programming languages and > thus feeling safe for the longest time ;-) > First, i should care about safety & stability of my own deployed application, then about possible exploits of different backends, such an OS or dynamic libraries. If i leave security responsibility on VM, then i can't guarantee the stability of my own application , and its makes no much sense talking, what exploits attacker could use through FFI interface or whatever, because first thing which under attack is my own application and its data. Would it make anyone happy, if hacker be able to destroy your image, destroy your app data etc etc, but unable to crack operating system? > Michael > > > _______________________________________________ > 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.

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Michael Rueger

Igor Stasenko wrote: > and besides: > VMs is packaged with FFI as dynamic library. > So, if you want extra safety - simply don't shipp your application > with this DLL. > > But still, if you allow arbitrary code to run in your image, then what > prevents script kiddie from doing following: the sandbox does that as it prevents writing of files in "interesting" locations like the VM directory. I'm all for using FFI/Alien, what I really tried to make people aware of is that by using FFI instead of plugins certain things become more dangerous. For standalone and server applications not loading any code from the outside this is not a problem at all. By using FFI we need to more aware though that we potentially open up a Squeak application to buffer overflow attacks, something that wasn't really possible before. So I didn't want to put any brakes on, but raise people's awareness about security. It's a bit like with the Mac: just because hackers haven't really cared about exploiting vulnerabilities doesn't mean the Mac is safe. And we Smalltalkers have considered us to use the Mac of programming languages and thus feeling safe for the longest time ;-) Michael

Nov. 30, 2008

Re: [Pharo-project] New pharo-dev based on 10178

by Adrian Lienhard

+1 On Nov 30, 2008, at 08:51 , StÃ©phane Ducasse wrote: > I would really like to make the halos menu only showing up when we > press shift and this for all the system. > The halso are cool for mroph and duplicating window for example but > they get in our way. > Stef > > >>>> >> We should remove this second world-menu. >> >>> The "other" world menu has an item "show main docking bar (M)", >>> turning it on results in a walkback: >>> >>> AnObsoleteBlueSmallLandColorTheme>>dockingBarColor should have >>> been implemented. >> >> Here is a fix. >> >> <DockingbarFix.cs> >> >> >> But the docking-bar needs some work in general... lots of things >> are accessible in the menues that should >> be removed. >> >>> >>> >>> The window look (Watery2) is quite slick ... so very non-squeaky :-) >> >> :-) >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> _______________________________________________ >> 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

Nov. 30, 2008

Re: [Pharo-project] free fonts

by Adrian Lienhard

On Nov 30, 2008, at 10:35 , StÃ©phane Ducasse wrote: > http://www.pinvoke.com/font/ > > I think that for the demo mode we should get a better font since > italic "" is not working well. Yes, and not only for the demo font, but *all* default fonts should be reconsidered now that we have the machinery in place. I don't think that the fonts of www.pinvoke.com/font/ are particularly well suited. From a mail I sent on September 22, considering the code font I wrote: I think Bitstream Vera Sans Mono would be quite good. I slightly prefer Monaco, which is shipped with OS X, but I don't know its license (http://en.wikipedia.org/wiki/Monaco_(typeface)) For an evaluation of programmer fonts see http://www.lowing.org/fonts/ Another list can be found here: http://wiki.macromates.com/Main/AlternativeFonts The latter list, for example includes http://www.ms-studio.com/FontSales/anonymous.html which looks nice too. Adrian > > Now it would be great to have a set of free font for pharo. > > stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2008

[Pharo-project] free fonts

by StÃ©phane Ducasse

http://www.pinvoke.com/font/ I think that for the demo mode we should get a better font since italic "" is not working well. Now it would be great to have a set of free font for pharo. stef

Nov. 30, 2008

Re: [Pharo-project] Re: FileList2 merged with FileList

by Marcus Denker

Hello HernÃ¡n! Thank you very much! This looks very good. I will harvest it soon. On 29.11.2008, at 23:44, HernÃ¡n Morales Durand wrote: > I forgot to mention, to install it: > > -Remove the Morphic-FileList category. > -Evaluate: > > FileStream fileIn: 'Morphic-FileList.st'. > FileStream fileIn: 'FileListNewReferences.st' > This file needs a small fix in the last version (I removed FileList2ModalDialogsTest). Easy to solve, I will just delete those methods before loading (no need to send a new file). Marcus > 2008/11/29 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > Issue 269: http://code.google.com/p/pharo/issues/detail?id=269&q=FileList2&colspec=ID%… > > Attachements: > Morphic-FileList.st contains FileList merged from old FileList and > FileList2 > Removed FileList2 references in FileListNewReferences.st > > Two issues: > -It is possible to establish a preference for saving a method > without modification of the authorship/annotation information ? > -Why methods have authors but classes don't ? > > Cheers > > HernÃ¡n > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 30, 2008

Re: [Pharo-project] Bug when loading Seaside in 10178

by Marcus Denker

On 29.11.2008, at 14:52, Damien Pollet wrote: > Just loading Seaside 2.8a1 in pharo (core or dev, using universes or > MC) 10178, we get a strange from PSUIManager >> modalMorphâ¦ not clear > if it's pharo or MC or Seaside's faultâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Can you add a bug-report to the bug-tracker? -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 30, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Marcus Denker

Hi, I think we should have FFI in the base-image. Not using a very good FFI to make talking to the outside world would be a mistake. The Outside, where *everthing* is happening... just look at how the libraries of MacOS progressed in the last 10 years compared to Squeak... Security... hard problem. We should solve it on a different level. Marcus On 30.11.2008, at 02:34, John M McIntosh wrote: > Ah well security. > > So the view is it would be nice to have Alien/FFI in the image & VM > so you can execute any operating system API you've rights to execute. > This enables folks to write smalltalk code and exploit operating > system features without having to rely on the difficult procedure of > creating a plugin and setting up a platform > development environment. It also provides for better support since > changes can be done by someone submitting a fix to MC somewhere, > versus relying on a handful of > people who do the plugin development. I personally think this is a > good idea if I ignore everything written below. > > Now once you allow the loading of arbitrary, non-signed, mystery > code from the internet you have the following: > > (a) well obviously a script has full user read/write access to the > file systems & network just using native squeak. The squeak > sandboxing attempts to limit that > but can be defeated and in my audit of the squeak platform api's > it's obvious most platforms consider primitive callers to be > friendly and not > attempt nasty things like buffer overflows or do other devious > things. No doubt any serious effort at exploitation would defeat the > current sandboxing. > > (b) Enabling FFI then allows the script to do lots more, likely > also exploit privilege escalation exploits etc, run arbitrary > binaries etc. Which is the > problem Michael refers to. > > > I'm not about to go anywhere near proposing any solutions since this > entire topic has had billions of $ spent on solving it. > > > On 29-Nov-08, at 12:06 PM, StÃ©phane Ducasse wrote: > >> Mike >> >> could you explain a bit more the scenario. >> would the people have to add a dll? >> >> Stef >> >> On Nov 29, 2008, at 10:25 AM, Michael Rueger wrote: >> >>> Marcus Denker wrote: >>>> I personally think that a good FFI is base fuctionality, e.g. it >>>> allows to >>>> move glue-code into the image that normally would be in primitives. >>> >>> The problem with FFI (and Alien) is that by using FFI and thus >>> having the FFI plugin installed you completely circumvent any >>> security you gain from the sandbox. >>> This is only really interesting for an environment like etoys >>> where you allow arbitrary scripts to be loaded. Right now we are >>> not supporting etoys, but the question is what, down the road, is >>> going to happen. >>> >>> Another question is how more use of FFI opens us up to issues >>> other languages have. So far Smalltalk wasn't hackable (on the >>> server), with FFI generally available it could be? >>> >>> If people vote this a non-issue I'm fine with it, but I wanted at >>> least to raise the issue at hand. >>> >>> Michael > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 30, 2008