- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2586 in pharo: line breaks lost on Linux when copying from one pharo image to another

by pharo＠googlecode.com

Comment #8 on issue 2586 by ryd...(a)gmail.com: line breaks lost on Linux when copying from one pharo image to another http://code.google.com/p/pharo/issues/detail?id=2586 This is a regression introduced recently, I think it belongs in 1.2 even though it's kinda late in release cycle. A working clipboard is nice to have :)

Jan. 28, 2011

Re: [Pharo-project] Issue 3376 in pharo: DisplayObject remove dependence to FileStream

by pharo＠googlecode.com

Comment #2 on issue 3376 by stephane...(a)gmail.com: DisplayObject remove dependence to FileStream http://code.google.com/p/pharo/issues/detail?id=3376 in 13024

Jan. 28, 2011

Re: [Pharo-project] Issue 3376 in pharo: DisplayObject remove dependence to FileStream

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 3376 by stephane...(a)gmail.com: DisplayObject remove dependence to FileStream http://code.google.com/p/pharo/issues/detail?id=3376 in 13024

Jan. 28, 2011

Re: [Pharo-project] Issue 2586 in pharo: line breaks lost on Linux when copying from one pharo image to another

by pharo＠googlecode.com

Updates: Status: Fixed Comment #7 on issue 2586 by ryd...(a)gmail.com: line breaks lost on Linux when copying from one pharo image to another http://code.google.com/p/pharo/issues/detail?id=2586 This change broke the clipboard on Windows, which does transformation of canonical CR's to CRLF's. A new fix, which preserves the functionality on other platforms than Unix is in Inbox, SLICE-Issue2586-UnbreakWindowsClipboard

Jan. 28, 2011

Re: [Pharo-project] [Seaside] state of the art in seaside/magritte/glorp on Squeak/OSX/FreeBSD

by Mariano Martinez Peck

On Thu, Jan 27, 2011 at 1:20 PM, Randal L. Schwartz <merlyn(a)stonehenge.com>wrote: > > So I've had my head buried in Perl for the past six months, and lost > track of where Seaside has gone. > > I know Seaside 3.0 is out. And Magritte/Pier have been updated (although > the docs still look amazingly sparse :). And there's something called > SqueakDBX for talking to Postgresql. > > My client has restarted the project we began a year ago but had to set > aside for economic reasons. I need to build a Seaside app that talks to > Postgresql, and runs on FreeBSD. I'd prefer to use something like > Glorp, but I'm not sure that's been updated in a while in the Squeak > world, unless SqueakDBX did it. > No. The Glorp version for Squeak/Pharo is still several years old. However, it has been updated at least to work in the latest Pharo (I guess squeak too but I am not sure). You can use Glorp directly and use the PostgreSQL native driver (where you don't need the postgres client libraries), or you can use GlorpDBX with SqueakDBX driver, where you need to install OpenDBX and the PostgreSQl libraries. > > So, what's the current state of the art for Seaside, Magritte, Glorp, > and Postgresql bindings for Squeak? And has anyone managed to get a > modern VM running on FreeBSD... I can't seem to get the latest sources > to build (too many Linuxisms). I'll be developing on OSX, so that's > reasonably secure. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

Jan. 28, 2011

Re: [Pharo-project] Issue 3377 in pharo: AppRegistry remoce dependence to UIManager

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 3377 by stephane...(a)gmail.com: AppRegistry remoce dependence to UIManager http://code.google.com/p/pharo/issues/detail?id=3377 in 13023

Jan. 28, 2011

Re: [Pharo-project] Issue 3379 in pharo: ToolSet remove dependence to UIManager

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3379 by stephane...(a)gmail.com: ToolSet remove dependence to UIManager http://code.google.com/p/pharo/issues/detail?id=3379 13023 We moved askDefault to UIManager as an extension

Jan. 28, 2011

Re: [Pharo-project] [squeak-dev] Accessing external resources in a cross-platform way

by David T. Lewis

On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote: > Let's say you want to resolve paths in a cross platform way > > Binaries @ 'MyExec' > Libraries @ 'MyLib' > SystemLibraries @ 'SystemLib' > etc. > > then Binaries is > > In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) " > and all standard locations including translations " > In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations " > etc > > Now you may say it is necessary to scan all directories to find > MyExec, yes but you may then save that location > > myBinaryLocation := Binaries @ 'MyExec'. > > so you scan for it just once. > > What do you think? it is already implemented anywhere? > If not what package do you think is more suitable or prepared for > implementing it? Hern??n, This is of course very platform dependent, and it is more complex than you might expect due to differences in file systems, operating systems, volume names (windows), environment variables and search path conventions. Both Windows and Unix use various seach paths accessible through environment variables, and the conventions for this tend to change over time with different OS versions. So it would probably be best to rely directly on those environment variables for identifying search paths. Aside from the conventions for default locations and search paths, some of what you are looking for may also be implemented for Windows and Unix in SqS/CommandShell in class ShellSyntax: My instances implement parsing of strings in a manner similar to a simple Unix command shell. I provide path name expansion in the context of an external file system, and support the syntax required for IO redirection. All file name globbing and PATH searching are implemented in Smalltalk rather than in C library functions or an external command shell. Most of my syntax is applicable for any operating system. Where needed, platform specific methods are in my "platform dependent" category. Currently, Unix and Windows are supported, and other platforms have not been tested. The primary difference between Unix and Windows support is that device names (such as 'C:') are used in Windows path strings. Separate current working directory strings are maintained for all Windows device names. For Unix, a single current working directory path is used. On Windows, this permits the CommandShell 'cd' command to support changing directories to another device without losing track of the current working directory for the previous device. Command pipeline syntax is not supported here. See CommandShell for the implementation of command pipelines. Dave

Jan. 28, 2011

[Pharo-project] [update 1.3] #13022

by StÃ©phane Ducasse

13022 ----- - Issue 3597: Fix RemoteString API. Thanks Benjamin van Ryseghem. - Fixed bold application in a text. - Removed a self haltOnce: 2 in mouseEnter. - Now we do not read back code annotation such as bold and italic. The idea is to only store code without styling annotation outside the code. It will simplify the rewrite of the system. Stef and Benjamin

Jan. 28, 2011

Re: [Pharo-project] Issue 3597 in pharo: Fix RemoteString API

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3597 by stephane...(a)gmail.com: Fix RemoteString API http://code.google.com/p/pharo/issues/detail?id=3597 in 13022

Jan. 28, 2011