Re: [Pharo-project] GoferApiTest failing (WinXP)
Lukas Renggli schrieb: running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see GoferApiTest#testSubDirectoryRepository failing. Are you sure that you use the latest Gofer code, because I think I fixed that a while back. I just ran the tests that come with PharoCore-1.0-10508 PharoCore-1.1-11196 using the image as it is. I updated to Gofer-Tests lr.115 and now I see, that #testSubDirectoryRepository has been removed in that version... It could be fixed by changing MCSubDirectoryRepository#description + ^ directory pathName, FileDirectory slash , '*' - ^ directory pathName, '/*' The current implementation works because '/' and '\' both are valid path separators on windows. Assuming '/' as path delimiter would cause trouble with MacFileDirectory - but that might be obsolete anyway. So may be the test is too strict? I bet that breaks the tests on all platforms other than Windows. Why do you think so? Is 'FileDirectory slash' broken on platforms other than Windows? Cheers, Christoph ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
On 14 February 2010 09:26, Ch Lamprecht ch.l.n...@online.de wrote: Lukas Renggli schrieb: running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see GoferApiTest#testSubDirectoryRepository failing. Are you sure that you use the latest Gofer code, because I think I fixed that a while back. I just ran the tests that come with PharoCore-1.0-10508 PharoCore-1.1-11196 using the image as it is. I updated to Gofer-Tests lr.115 and now I see, that #testSubDirectoryRepository has been removed in that version... It could be fixed by changing MCSubDirectoryRepository#description + ^ directory pathName, FileDirectory slash , '*' - ^ directory pathName, '/*' The current implementation works because '/' and '\' both are valid path separators on windows. Assuming '/' as path delimiter would cause trouble with MacFileDirectory - but that might be obsolete anyway. So may be the test is too strict? I bet that breaks the tests on all platforms other than Windows. Why do you think so? Is 'FileDirectory slash' broken on platforms other than Windows? All code that uses FileDirectory is full of these kind of bugs. Working with paths and file-names on the bases of strings is never really platform independent. Pharo should move on and adopt Filesystem. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem
hi Colin I guess he missed that, so let me answer. Is there a way not to have to specify the FileSystem to create a stream for a file on disk? str := FSUnixFilesystem new writeStreamOn: 'giffle'. str nextPutAll: 'zz'. str close - str := 'giffle' asWriteStream str nextPutAll: 'zz'. str close First of all you should not hardcode the unix platform. Instead let the system resolve the platform for you: (FSDiskFilesystem current / 'griffle') writeStream At the moment there is no shortcut for this on String. I think it would make sense to add a method #asFilesystemReference that would try to guess the right filesystem and answer a reference. So then one could write: 'griffle' asFilesystemReference writeStream 'http://www.lukas-renggli.ch' asFilesystemReference readStream ... currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] currentFolder allChildren do: [ :each | Do I have to use an FSPreOrderGuide? Are there some behavior like doWithAllFiles already defined? Yes, in the enumeration protocol of FSReference. There are only a few algorithms there, but that will probably grow over time. The FSPreOrderGuide is an internal implementation artifact, it should not be used directly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
Are there some examples (not tests)? Mason and Monticello 2 use it, as far as I know. What is the difference between FSReference and FSPath? Did you read the class comments? FSPath: I an abstract filesystem path, independent of the string representation used to describe paths on a specific filesystem. I provide methods for navigating the filesystem hierarchy and working with absolute and relative paths. I only refer to a concrete file or directory with regard to a specific filesystem. FSReference: I combine a filesystem and path, which is sufficient to refer to a concrete file or directory. I provide methods for navigating my filesystem, performing filesystem operations and opening and closing files. I am the primary mechanism for working with files and directories. So most likely you are only interested in FSReference. FSPath is only used for relative paths independent of the filesystem, or path that cross or are independent of filesystem boundaries. For example how can I print in the Transcript all the files in my current dir? FSDiskFilesystem current working children Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem
2010/2/14 Lukas Renggli reng...@gmail.com: hi Colin I guess he missed that, so let me answer. Is there a way not to have to specify the FileSystem to create a stream for a file on disk? str := FSUnixFilesystem new writeStreamOn: 'giffle'. str nextPutAll: 'zz'. str close - str := 'giffle' asWriteStream str nextPutAll: 'zz'. str close First of all you should not hardcode the unix platform. Instead let the system resolve the platform for you: (FSDiskFilesystem current / 'griffle') writeStream At the moment there is no shortcut for this on String. I think it would make sense to add a method #asFilesystemReference that would try to guess the right filesystem and answer a reference. So then one could write: 'griffle' asFilesystemReference writeStream 'http://www.lukas-renggli.ch' asFilesystemReference readStream ... Do we really reference the file-system or just a file ? asFileReference or asFilename (VW) would be just fine to my own taste. Nicolas currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] currentFolder allChildren do: [ :each | Do I have to use an FSPreOrderGuide? Are there some behavior like doWithAllFiles already defined? Yes, in the enumeration protocol of FSReference. There are only a few algorithms there, but that will probably grow over time. The FSPreOrderGuide is an internal implementation artifact, it should not be used directly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem
Do we really reference the file-system or just a file ? asFileReference or asFilename (VW) would be just fine to my own taste. It can be a directory or filename. It does not have to exist (yet). I agree that the name is long and that there are probably better ones. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About using toolbuilder
I tried to use toolbuilder to open tools like the changeSorter and I always got a rather small window. So I checked in Squeak and the buildPluggableWindow method is different Should we integrate this changes? http://code.google.com/p/pharo/issues/detail?id=1963 buildPluggableWindow: aSpec | widget children label | aSpec layout == #proportional ifFalse:[ This needs to be implemented - probably by adding a single pane and then the rest ^self error: 'Not implemented'. ]. widget := PluggableStandardWindow new. self register: widget id: aSpec name. widget model: aSpec model. (label := aSpec label) ifNotNil:[ label isSymbol ifTrue:[widget getLabelSelector: label] ifFalse:[widget setLabel: label]]. children := aSpec children. children isSymbol ifTrue:[ widget getChildrenSelector: children. widget update: children. children := #(). ]. widget closeWindowSelector: aSpec closeAction. panes := OrderedCollection new. self buildAll: children in: widget. - aSpec extent ifNotNil:[widget extent: aSpec extent]. + self buildHelpFor: widget spec: aSpec. + widget bounds: (RealEstateAgent + initialFrameFor: widget + initialExtent: (aSpec extent ifNil:[widget initialExtent]) + world: self currentWorld). widget setUpdatablePanesFrom: panes. ^widget A related question is do we get rid of the method creation that do not rely on toolbuilder? I think that it would make sense. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
It is not a code problem. It is a social/political problem. Right now yes: 16rff now is working in pharo as well as Squeak. The question is how much do we put on the table to make what we believe important done. In addition do you prefer an old greyish smalltalk or a new one showing interest and trying to build new stuff? I chose my camp and backward compatibility will not keep pharo in a closet or in a can http://en.wikipedia.org/wiki/Nothing_Safe:_Best_of_the_Box Now people can use VW, Dolphin or VA if they want. I would have prefer that non open source smalltalk show the way (they did partly (parcel, pragma) but I cannot run dolphin on mac or linux, VW nearly missed Seaside). Now the question is what people do for their dreams. Pharo is not my daily work. I have to do a lot more and other tasks. I work on it every time I can and my goal is to make it cool: first class instance variable, well designed, modular Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Lukas sad sad. May be eliot was not aware of your work. may be we should ressurect what you did and now we do not care about the FFI maintainer :) We can have PharoFFI if needed. Stef I'd like to discuss, what changes to compiler we may introduce to allow FFI to handle pragmas in non-intrusive manner. I suppose something, like registration mechanism for compiler, where any external package can register and provide own handler(s) for pragmas. Then, of course, an Encoder should have a public API, which would allow such handlers to add/change literals and method header. We already having at least another use of pragmas - preferences. It's also could use same mechanism which can be used to notify a preferences system about appearance of new or removal existing preferences as a result of method compilation. In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks. The idea was that you could add methods with a specific pragma to one of the compiler classes (I don't remember which one). There was also one such method for each of the Smalltalk primitives currently supported (#primitive:, 3primitive:module:, ...). When encountering a pragma in the source code the compiler would check if this was a compiler-pragma with the same name defined and perform that method. In the case of the primitive the compiler would change the compile method to use the configured primitive. A very strait forward use of pragmas. However the functionality that made compiler pragmas and primitives extensible is gone today even in Pharo. For reasons unknown to me Eliot removed all the code when he added the closure support. Back to hacking and patching the compiler. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
sad sad. May be eliot was not aware of your work. may be we should ressurect what you did and now we do not care about the FFI maintainer :) We can have PharoFFI if needed. I don't have a problem with that. I am just saying that we've been there and we've done that :-) I don't care about FFI. According to Fernando Alien seems the way to go nowadays anyway. As far as I know it does not even depend on the compiler. What is way better than anything else. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Ok thanks for the historical refresh. Some people may now understand why we
finally decided to do Pharo.
Now let us stop ranting and think about the blue sky of the new horizon.
What do we do in Pharo 1.1?
:)
I'm full ears open.
Stef
It is interesting to note that of course, after this was added to 3.9,
there was
someone *very hard* arguing that adding Pragmas was a very dumb idea...
Who that person was is left as an exercise to the reader of course ;-)
Hint: FFI has its own proprietary hardcoded pragma format. It
unnecessary complicates the compiler even when not loaded. Not to
mention that it breaks all tools that have their own parser, such as
RB for example.
I'd like to discuss, what changes to compiler we may introduce to allow FFI
to handle pragmas in non-intrusive manner.
Very simple: FFI just needs to use the pragmas as introduces in 3.9, than
remove all
knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful?
cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'
of that would be changed so that the stuff inside the would be a standard
Smalltalk Message expression, problem solved.
to illustrate... using the SMaCC grammar of the NewCompiler (a bit
simplified) as extendend for Pragmas, Primitives and FFI by
Mathiue Suen.
A method in Squeak has Pragmas:
Method:
| MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:};
So they are difined like this (we can have multiple ones):
Pragmas:
PragmaMessage
{#pragma:}
| Pragmas PragmaMessage
{#pragmas:}
So it's quite simple: there is one message expression inside... simple. But
there is FFI. Primitives are
there, too, but that's not really a problem: they fit in the Pragmas.
primitive: 15 is a valid message in Smalltalk.
(Math did the gramar for primitives to have nice error messages, but that's
not needed)
PragmaMessage:
Apicall
{#messagePragma:}
| Primitive
{#messagePragma:}
| MessagePragma
{#messagePragma:};
How Primitive and MessagePragma are done is not important. But we need Gramar
rules just to be able to parse
FFI:
Apicall:
TypeCall ExternalType IndexName ( ParameterApicall rightParentheses
{#externalCall:}
| TypeCall ExternalType IndexName ( ParameterApicall rightParentheses
module: string {#externalModuleCall:};
IndexName:
string
{#externalFunction:}
| number
{#externalIndex:};
TypeCall:
apicall:
{#callConvention:}
| cdecl:
{#callConvention:};
ParameterApicall:
ExternalType
{#parameterExtCall:}
| ParameterApicall ExternalType
{#parametersExtCall:};
ExternalType:
name
{#externalType:}
| name *
{#externalTypePointer:};
And this is *always* in the Grammar. Even when FFI is not loaded! (a nice
example where our simple notion of
modularity brakes down completely).
No the solution here is simple: a small trivial modification to FFI to use
the Evil Pragmas as introduced by the Dumb
People (tm) in 3.9:
cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'
or *whatever*. just something that is a valid Smalltalk message expression...
can't be hard, can it?
Ah. And and about notion of modularity... of course the problem how can I
extend the language from
my package without having to spread code over the parser, compiler, debugger,
browser... is intellectually
an interesting one. And, oh, we are payed for finding these kind of Problems
and especially solving these Problems
in a way that goes beyond of just doing a pragmatic and simple solution (aka
what I described here).
(They call it Academic Research. Involves mostly a programming language
called TeX and can be very boring at times
but it's complementary to the practical world... in a very interesting way).
And int his context the result is, of course, tataaa: Lukas' Helvetia:
http://scg.unibe.ch/research/helvetia/languageboxes
See? So *everything* fits together... research and non-research, problems and
solutions (on multiple levels),
progress in the
Re: [Pharo-project] [ANN] HelpSystem (was ProfStef)
Am Samstag, 13. Februar 2010 22:13:27 schrieb Torsten Bergmann: I have implemented some authoring capabilities in ProfStefBrowser to create new tutorials Yes, authoring capabilities would be cool to have. But first we have to find out what the content really should be and how it should be represented (simple text, markup, active morphs, ...) Some kind of simple markup language to have for example links to other pages or books, or to execute code snippets with a single mouse click Do you know the Squeak welcome workspace? It provided something like this - a Text could define runs to change style, color of text or even have clickable links with Smalltalk code behind - dont know if this is still possible in Pharo since parts of Morphic are removed. On the other hand it was Squeak only - hard to create from tyical documentation formats (text, HTML, ...) Maybe we could reactive code from Scamper (the Squeak web browser) for simple HTML like text styling. Using a subset of HTML as description would also allow us to publish the help contents on webpages later. I also remember a full webbrowser written in Smalltalk (VW). Meanwhile it is open source (MIT), see [1] ... so lets just reactivate it ;) We all have many ideas (like yours with the debugger) - but first I would like to see a minimal version for a help system: - provide help contents as simple ascii text (as it is now) - ability to jump from a tool to a specific page (like F1-help on Windows) we can use a simple unique key which is defined in HelpTopic already. - ability to define order of pages together with order of (sub)books With a minimal help tool (included in the dev-image) we can provide help to beginners and start documenting Pharo. As a second step we can work on better markup, authoring, active content I fully agree with this plan. So let's get the definition of the structure of help contents right, so people can start using and especially writing content quickly without having to fear that they need to restructure their content with the next release. All the presentation stuff of the actual content can be done later and does not decrease the value of the documents already written. ... However - the repo is open for any contribution... Let's coordinate, I have little time and do this for fun, but I would love to help. Maybe add a document to HelpSystem with a basic vision and all the ideas for the future? NowIt is not clear for me the differences between HelpSystem and ProfStef. HelpSystem is like a normal help system you know from Eclipse, KDE, Windows, ... It is more a reference/documentation kind of thing. ProfStef is an interactive tutorial usefull to teach things step by step. I think that HelpSystem with little work can provide a superset in functionality of ProfStef. As I perceive it, the goals are different. ProfStef is to be simple, fun and small. And to accomplish this it is basically full featured and finished. HelpSystem is to be comprehensive and needs a lot of work. I was excited when I found out that the debugger is so well integrated in the work flow that debugging isn't something that distracts from coding. I would love to have something that somehow makes the experience of documentation similar to that. And that's why it is a good idea to decouple these two projects. Help system is new ? Yes, developed yesterday. should they be merged? Hey, we just decoupled ... why merge again ;) Read [2] when we should use one and when the other ? ProfStef is for an introduction (5min course) on Pharo or tools, an interactive tutorial to introduce Smalltalk or basic concepts. It is more workspace oriented. See Laurents comments. HelpSystem is more a general help system with a browser that should be available as a base framework so tools can provide help texts/contents to users. Bye T. [1] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true printTitle=Im_back..._but_SWS_isntentry=3364012145 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021782. html ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
Of course I read them :)
this is the first thing I do.
Are there some examples (not tests)?
Mason and Monticello 2 use it, as far as I know.
sure
Now I mean little examples in the sense of a little tutorial (see below the rio
one).
I will probably start to write something like that for me.
What is the difference between FSReference and FSPath?
Did you read the class comments?
FSPath: I an abstract filesystem path, independent of the string
representation used to describe paths on a specific filesystem. I
provide methods for navigating the filesystem hierarchy and working
with absolute and relative paths. I only refer to a concrete file or
directory with regard to a specific filesystem.
FSReference: I combine a filesystem and path, which is sufficient to
refer to a concrete file or directory. I provide methods for
navigating my filesystem, performing filesystem operations and opening
and closing files. I am the primary mechanism for working with files
and directories.
So most likely you are only interested in FSReference. FSPath is only
used for relative paths independent of the filesystem, or path that
cross or are independent of filesystem boundaries.
Ok so FSPath is a kind of internal representation of /usr/bin/
For example how can I print in the Transcript all the files in my current
dir?
FSDiskFilesystem current working children
Instantiating and Building Paths
The most concise method for creating a Rio is via: 1.below, the following are
equivalent:
• 'myFile.txt' asRio
• Cwd / 'myFile.txt'
• Rio / 'myFile.txt'
• Rio new:'myFile.txt' - the verbose form
Rio's may be constucted using the #/ and #, operators like so.
Cwd / 'package-cache' / 'Rio-Core' , '-kph.20' , '.mcz'.
Deconstructing the Rio Path and File Name
Given myFile := Cwd / 'myFile.3.txt'.
• myFile full = '/media/hda1/squeak/myFile.3.txt'
• myFile fileName = 'myFile.3.txt'
• myFile parent = '/media/hda1/squeak'
• myFile base = 'myFile'
• myFile version = 3
• myFile ext = 'txt'
• myFile path = ''.
• myFile full split = #('/' 'media' 'hda1' 'squeak' 'myFile.3.txt')
Adjusting the Rio Path and File Name
Given myFile := Cwd / 'myFile.3.txt'.
(#parent: and #full: will set the path relative to the default directory).
• myFile fileName: 'another.txt' = (Rio new:'another.txt').
• myFile base: 'temp' = (Rio new: 'temp.3.txt').
• myFile version: 4 = (Rio new: 'myFile.4.txt').
• myFile ext: 'html' = (Rio new: 'myFile.3.html').
• myFile parent: 'temp' = (Rio new: 'temp/myFile.3.txt')
• myFile full: '/media/hda1/squeak/temp/myFile.3.txt' = (Rio new:
'temp/myFile.3.txt')
File Versions Helpers
If there exists a file, Cwd / 'temp.4.txt'. Then there are some utilities for
obtaining the latest and next version file rio's.
• 'temp.txt' asRio latestVersion = (Rio new: 'temp.4.txt').
• 'temp.txt' asRio nextVersion = (Rio new: 'temp.5.txt').
A Word About Style
Rio may be used in two distinct styles. In addition to the traditional
smalltalk cascading messages style, Rio supports a sentence like 'sequential'
style. Whenever an example below uses the 'sequential' style for conciseness,
suffice to say there is a traditional equivalent.
sequential:
'myFile.zip' asRio zip addAll: '/tmp/files' asRio all files
cascading:
(Rio new: 'myFile)
setModeToZip;
addAll: ((Rio new:'/tmp/files')
setModeToRecursive;
yourself) files;
yourself.
Introducing Modes - 'Renaming' Mode
When a Rio is #setModeToRenaming, all of the above fileName and path
manipulations are simultaneously actualized on disk. Below is an example using
Rio's 'sequential' style for configuring modes:
• myFile rename base: 'temp'. = is equivalent to = 'myFile.3.txt'
asRio renameTo: 'temp.3.txt'.
When a mode is set using 'cascading' style, (e.g. #setModeToRenaming) the mode
flag is set on the given instance as you would expect. In contrast, when a mode
is set in sequential style, a new instance is created, making the mode setting
temporary for the remainer of that 'sequential sentence'. This convention
applies to all modes. e.g.
• cascading: (myFile setModeToRenaming; yourself) base:'temp'. – the
renamng mode flag of myFile is set.
• sequential: myFile rename base: 'temp'. – myFile itself is untouched,
the renaming mode flag is set in the myFile copy that performs #base:
File Stat
All of the typical stat information about files and directories is directly
obtainable from a Rio.
• myFile fileSize
• myFile modificationTime returns a DateAndTime
• myFile creationTime returns a DateAndTime
• myFile isFile
• myFile exists
• myFile isDirectory
Directory Queries #select:ing
Internally the operating
Re: [Pharo-project] GoferApiTest failing (WinXP)
All code that uses FileDirectory is full of these kind of bugs. Working with paths and file-names on the bases of strings is never really platform independent. Pharo should move on and adopt Filesystem. This is the idea. Now lukas I would like to see the interface of FileSystem a bit more user friendly see the reply to our answers. I would love to use FileSystem for Coral so the api is really important for scripting. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Yes Alien is the way to go. Stef On Feb 14, 2010, at 10:28 AM, Lukas Renggli wrote: sad sad. May be eliot was not aware of your work. may be we should ressurect what you did and now we do not care about the FFI maintainer :) We can have PharoFFI if needed. I don't have a problem with that. I am just saying that we've been there and we've done that :-) I don't care about FFI. According to Fernando Alien seems the way to go nowadays anyway. As far as I know it does not even depend on the compiler. What is way better than anything else. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] HelpSystem (was ProfStef)
Yes, authoring capabilities would be cool to have. But first we have to find out what the content really should be and how it should be represented (simple text, markup, active morphs, ...) KISS and learn. Better a simple working than a complex unfinished. Some kind of simple markup language to have for example links to other pages or books, or to execute code snippets with a single mouse click Do you know the Squeak welcome workspace? It provided something like this - a Text could define runs to change style, color of text or even have clickable links with Smalltalk code behind - dont know if this is still possible in Pharo since parts of Morphic are removed. On the other hand it was Squeak only - hard to create from tyical documentation formats (text, HTML, ...) Maybe we could reactive code from Scamper (the Squeak web browser) for simple HTML like text styling. Using a subset of HTML as description would also allow us to publish the help contents on webpages later. I also remember a full webbrowser written in Smalltalk (VW). Meanwhile it is open source (MIT), see [1] ... so lets just reactivate it ;) interesting. We all have many ideas (like yours with the debugger) - but first I would like to see a minimal version for a help system: - provide help contents as simple ascii text (as it is now) - ability to jump from a tool to a specific page (like F1-help on Windows) we can use a simple unique key which is defined in HelpTopic already. - ability to define order of pages together with order of (sub)books good plan With a minimal help tool (included in the dev-image) we can provide help to beginners and start documenting Pharo. Yes Something that I would like is the following: a simple way to script UML like diagrams. I would like a graphical way to express design and I want no magic so here is what I want comp := UClass named: 'ProgramNode'. comp at: 1...@100. comp tagged: 'Composite hiearchy'. vist := UClass named: 'ProgramNodeEnumerator'. comp at: 2...@100. comp tagged: 'Visitor hiearchy'. sub := UClass named: 'MessageSendNode'. sub at: 1...@200. sub extend: comp. comp talkTo: vis with: 'acceptVisitor/visit*' then we store that in the package and we with clik on it is is displayed. I should add that to DrDoc. But if somebody want to help this would be great. As a second step we can work on better markup, authoring, active content ... However - the repo is open for any contribution... NowIt is not clear for me the differences between HelpSystem and ProfStef. HelpSystem is like a normal help system you know from Eclipse, KDE, Windows, ... It is more a reference/documentation kind of thing. ProfStef is an interactive tutorial usefull to teach things step by step. Help system is new ? Yes, developed yesterday. should they be merged? Hey, we just decoupled ... why merge again ;) Read [2] when we should use one and when the other ? ProfStef is for an introduction (5min course) on Pharo or tools, an interactive tutorial to introduce Smalltalk or basic concepts. It is more workspace oriented. See Laurents comments. HelpSystem is more a general help system with a browser that should be available as a base framework so tools can provide help texts/contents to users. Bye T. [1] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=trueprintTitle=Im_back..._but_SWS_isntentry=3364012145 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021782.html -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore
did you check the configurationOfFFI ??? Does it exist? Stef On Feb 14, 2010, at 7:45 AM, Yanni Chiu wrote: Oops, this was on Pharo. I just checked Squeak3.11-9371-alpha.zip, and ScriptLoaderloadFFI does not exist there. Anyhow, what is the proper way to load FFI? Yanni Chiu wrote: ScriptLoader loadFFI now fails because the package FFI-Examples is no longer in the repository. Does ScriptLoader need to be updated, or was the package deleted accidentally? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
On Sun, 14 Feb 2010, Stéphane Ducasse wrote: Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only Levente Stef On Feb 14, 2010, at 10:28 AM, Lukas Renggli wrote: sad sad. May be eliot was not aware of your work. may be we should ressurect what you did and now we do not care about the FFI maintainer :) We can have PharoFFI if needed. I don't have a problem with that. I am just saying that we've been there and we've done that :-) I don't care about FFI. According to Fernando Alien seems the way to go nowadays anyway. As far as I know it does not even depend on the compiler. What is way better than anything else. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem
First of all you should not hardcode the unix platform. Instead let the system resolve the platform for you: (FSDiskFilesystem current / 'griffle') writeStream I prefer that. I was not happy with my code. At the moment there is no shortcut for this on String. I think it would make sense to add a method #asFilesystemReference that would try to guess the right filesystem and answer a reference. So then one could write: 'griffle' asFilesystemReference writeStream 'http://www.lukas-renggli.ch' asFilesystemReference readStream ... currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] currentFolder allChildren do: [ :each | FSDiskFilesystem current workingDirectory allChildren do not work :( I do not understand why workingDirectory return a path and not a reference because this is not workingDirectoryPath So how can I get all the files in my current direct directory FSDiskFilesystem current childrenAt: FSDiskFilesystem current workingDirectory looks ugly Do I have to use an FSPreOrderGuide? Are there some behavior like doWithAllFiles already defined? Yes, in the enumeration protocol of FSReference. There are only a few algorithms there, but that will probably grow over time. The FSPreOrderGuide is an internal implementation artifact, it should not be used directly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only I'm not knowledgeable enough but I refer here to some discussions I got with eliot when we were at amsterdam. The comments I heard on the FFI implementation were not that positive. Now may be there is a road for FFI and Alien and it would be good to have the extension lukas did in 3.9. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
This is the idea. Now lukas I would like to see the interface of FileSystem a bit more user friendly see the reply to our answers. I would love to use FileSystem for Coral so the api is really important for scripting. Yeah, the Filesystem API is currently quite verbose in many parts. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
I think that with some practice it can stabilize in something nice. I do not know if colin is interested into that - probably. Stef On Feb 14, 2010, at 12:01 PM, Lukas Renggli wrote: This is the idea. Now lukas I would like to see the interface of FileSystem a bit more user friendly see the reply to our answers. I would love to use FileSystem for Coral so the api is really important for scripting. Yeah, the Filesystem API is currently quite verbose in many parts. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Arghh it's almost done but I have a bug:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents readStream)
fails: image format is not recognized.
In JPEGReadWriter class understandsImageFormat
aStream next = 16rFF answer false ???
- aStream next answers a Character instance
- 16rFF is a SmallInteger
- both equals 255.
What is the right way to correct that ?
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
On Sun, 14 Feb 2010, laurent laffont wrote:
Arghh it's almost done but I have a bug:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents readStream)
fails: image format is not recognized.
In JPEGReadWriter class understandsImageFormat
aStream next = 16rFF answer false ???
- aStream next answers a Character instance
- 16rFF is a SmallInteger
- both equals 255.
What is the right way to correct that ?
Make sure that the stream is binary:
SketchMorph fromStream:
('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
laurent
did you check if it was working on older version?
Which version are you using now?
I tried in Squeak and latest pharo and they both fail.
Stef
On Feb 14, 2010, at 1:01 PM, laurent laffont wrote:
Arghh it's almost done but I have a bug:
SketchMorph fromStream:
('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents readStream)
fails: image format is not recognized.
In JPEGReadWriter class understandsImageFormat
aStream next = 16rFF answer false ???
- aStream next answers a Character instance
- 16rFF is a SmallInteger
- both equals 255.
What is the right way to correct that ?
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
laurent have a look in the network chapter of the new blue book (collective
book available on web page)
because I do not remember but you could find some snippets going in the same
sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Make sure that the stream is binary:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore
Try not to use ScriptLoader anymore to load projects or packages. To install FFI, use the Metacello configuration, like this: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ((Smalltalk at: #ConfigurationOfFFI) project version: '1.0') load. Cheers Mariano On Sun, Feb 14, 2010 at 10:48 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: did you check the configurationOfFFI ??? Does it exist? Stef On Feb 14, 2010, at 7:45 AM, Yanni Chiu wrote: Oops, this was on Pharo. I just checked Squeak3.11-9371-alpha.zip, and ScriptLoaderloadFFI does not exist there. Anyhow, what is the proper way to load FFI? Yanni Chiu wrote: ScriptLoader loadFFI now fails because the package FFI-Examples is no longer in the repository. Does ScriptLoader need to be updated, or was the package deleted accidentally? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. Cheers Mariano On Sun, Feb 14, 2010 at 11:44 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only I'm not knowledgeable enough but I refer here to some discussions I got with eliot when we were at amsterdam. The comments I heard on the FFI implementation were not that positive. Now may be there is a road for FFI and Alien and it would be good to have the extension lukas did in 3.9. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
On Sun, Feb 14, 2010 at 12:46 AM, Ch Lamprecht ch.l.n...@online.de wrote:
Hello to everybody,
running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see
GoferApiTest#testSubDirectoryRepository failing.
It could be fixed by changing
MCSubDirectoryRepository#description
+ ^ directory pathName, FileDirectory slash , '*'
- ^ directory pathName, '/*'
The current implementation works because '/' and '\' both are valid path
separators on windows. Assuming '/' as path delimiter would cause trouble
with
MacFileDirectory - but that might be obsolete anyway.
So may be the test is too strict?
Hi Christoph. First, welcome! I hope you enjoy.
It was already reported. See
http://n4.nabble.com/Failing-Gofer-test-in-windows-WAS-BetaTesting-ANN-Pharo1-0-10507-rc2dev10-01-2-td1294890.html#a1294890
Thanks
Mariano
I just started to follow this list and the Pharo project ('Recreational
programmer' btw. - thanks for the kind welcome message ;) ). Should I
report
this? And if so: It is a MC issue, should it be reported using the Pharo
tracker
or somewere else?
Cheers, Christoph
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] HelpSystem implementation
Hi Thorsten! I have two questions regarding your implementation: - What is the reason to have HelpBuilder and to create a hierarchy of HelpTopic instances mirroring the layout of the actual content classes? Why not use the class objects directly? - Why do you use pragmas for the titles of the pages? If I understand correctly, pragmas are for metadata of methods, but it seems to me that the title of a page belongs to its data just as much as its contents do. Danny ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Stef,
I've always understood why you launched Pharo.
On FFI/Alien and blocking the entire VM, I injected Dolphin's overlapped calls
into a discussion of the (rather serious) problems that can arise when
something does not return as soon as expected (or at all), and somebody with
good VM awareness (I do not recall who[*]) described a way to get around it. I
recall thinking what a loss it is that good ideas often don't get packaged for
general use.
FWIW, here are my suggestions for ideas that should be given high priority:
(1) Alien plugins for Linux and Windows; Alien as a mac-only entity is far less
attractive than a cross-platform alternative.
(2) For FFI, we need a generic callback mechanism. It sounds as though one can
be built using a plugin and some indirection.
(3) For FFI and Alien, we need something like Dolphin's overlapped calls.
Hopefully a generic solution that starts a thread and waits on a semaphore can
be created once, and perhaps eventually enhanced with some thread pooling
options. For now, I'd take one os thread per call, or (perhaps the ideal) one
os thread per Smalltalk process blocked on such a call, as I think Dolphin does
now, in part due to Windows stupidities.
I also recall a lengthy discussion about efficiency in making calls to COM
objects from Dolphin, with someone arguing very hard to make calls a certain
way because the alternative (while much simpler) was too slow. The flaw in
that argument was that calls in question were by nature few and infrequent; the
overhead of making the call was dwarfed by the work that resulted. Much of my
use of FFI is similar. I am not arguing in favor of inefficient calls, but a
sub-optimal but flexible way to make a callback (FFI) and to make a call on an
os thread (FFI/Alien) would be much appreciated in most situations, even if it
takes a few extra milliseconds compared to something optimally coded if I had
time and knowledge to do so. I do not make millions of external calls; I make
a few that do millions of floating point operations. A little extra time to
put a socket connect (thinking OpenSSL) call on a background thread is trivial
next to the cost of having a direct call go into limbo and hang a server
process.
Bill
[*] seriously, it might have been the FFI maintainer or somebody else. I do
recall that whoever it is knows a lot more about the vm than I do.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse
[stephane.duca...@inria.fr]
Sent: Sunday, February 14, 2010 4:30 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo
changing the game)
Ok thanks for the historical refresh. Some people may now understand why we
finally decided to do Pharo.
Now let us stop ranting and think about the blue sky of the new horizon.
What do we do in Pharo 1.1?
:)
I'm full ears open.
Stef
It is interesting to note that of course, after this was added to 3.9,
there was
someone *very hard* arguing that adding Pragmas was a very dumb idea...
Who that person was is left as an exercise to the reader of course ;-)
Hint: FFI has its own proprietary hardcoded pragma format. It
unnecessary complicates the compiler even when not loaded. Not to
mention that it breaks all tools that have their own parser, such as
RB for example.
I'd like to discuss, what changes to compiler we may introduce to allow FFI
to handle pragmas in non-intrusive manner.
Very simple: FFI just needs to use the pragmas as introduces in 3.9, than
remove all
knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful?
cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'
of that would be changed so that the stuff inside the would be a standard
Smalltalk Message expression, problem solved.
to illustrate... using the SMaCC grammar of the NewCompiler (a bit
simplified) as extendend for Pragmas, Primitives and FFI by
Mathiue Suen.
A method in Squeak has Pragmas:
Method:
| MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:};
So they are difined like this (we can have multiple ones):
Pragmas:
PragmaMessage
{#pragma:}
| Pragmas PragmaMessage
{#pragmas:}
So it's quite simple: there is one message expression inside... simple. But
there is FFI. Primitives are
there, too, but that's not really a problem: they fit in the Pragmas.
primitive: 15 is a valid message in Smalltalk.
(Math did the gramar for primitives to have nice error messages, but that's
not needed)
PragmaMessage:
Apicall
{#messagePragma:}
| Primitive
Re: [Pharo-project] web services, pharo
;)
BTW did you convert my old videos?
Stef
On Feb 14, 2010, at 1:20 PM, laurent laffont wrote:
Make sure that the stream is binary:
SketchMorph fromStream:
('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
On Feb 14, 2010, at 4:01 PM, Schwab,Wilhelm K wrote:
Stef,
I've always understood why you launched Pharo.
On FFI/Alien and blocking the entire VM, I injected Dolphin's overlapped
calls into a discussion of the (rather serious) problems that can arise when
something does not return as soon as expected (or at all), and somebody with
good VM awareness (I do not recall who[*]) described a way to get around it.
I recall thinking what a loss it is that good ideas often don't get packaged
for general use.
FWIW, here are my suggestions for ideas that should be given high priority:
I would like to be able to do it myself but I don't know how to do it.
(1) Alien plugins for Linux and Windows; Alien as a mac-only entity is far
less attractive than a cross-platform alternative.
yes
we should get the one of linux running since there was a fix.
(2) For FFI, we need a generic callback mechanism. It sounds as though one
can be built using a plugin and some indirection.
(3) For FFI and Alien, we need something like Dolphin's overlapped calls.
Hopefully a generic solution that starts a thread and waits on a semaphore
can be created once, and perhaps eventually enhanced with some thread pooling
options. For now, I'd take one os thread per call, or (perhaps the ideal)
one os thread per Smalltalk process blocked on such a call, as I think
Dolphin does now, in part due to Windows stupidities.
I also recall a lengthy discussion about efficiency in making calls to COM
objects from Dolphin, with someone arguing very hard to make calls a certain
way because the alternative (while much simpler) was too slow. The flaw in
that argument was that calls in question were by nature few and infrequent;
the overhead of making the call was dwarfed by the work that resulted. Much
of my use of FFI is similar. I am not arguing in favor of inefficient calls,
but a sub-optimal but flexible way to make a callback (FFI) and to make a
call on an os thread (FFI/Alien) would be much appreciated in most situations,
I see
even if it takes a few extra milliseconds compared to something optimally
coded if I had time and knowledge to do so. I do not make millions of
external calls; I make a few that do millions of floating point operations.
A little extra time to put a socket connect (thinking OpenSSL) call on a
background thread is trivial next to the cost of having a direct call go into
limbo and hang a server process.
Bill
[*] seriously, it might have been the FFI maintainer or somebody else. I
do recall that whoever it is knows a lot more about the vm than I do.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse
[stephane.duca...@inria.fr]
Sent: Sunday, February 14, 2010 4:30 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo
changing the game)
Ok thanks for the historical refresh. Some people may now understand why we
finally decided to do Pharo.
Now let us stop ranting and think about the blue sky of the new horizon.
What do we do in Pharo 1.1?
:)
I'm full ears open.
Stef
It is interesting to note that of course, after this was added to 3.9,
there was
someone *very hard* arguing that adding Pragmas was a very dumb idea...
Who that person was is left as an exercise to the reader of course ;-)
Hint: FFI has its own proprietary hardcoded pragma format. It
unnecessary complicates the compiler even when not loaded. Not to
mention that it breaks all tools that have their own parser, such as
RB for example.
I'd like to discuss, what changes to compiler we may introduce to allow FFI
to handle pragmas in non-intrusive manner.
Very simple: FFI just needs to use the pragmas as introduces in 3.9, than
remove all
knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful?
cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'
of that would be changed so that the stuff inside the would be a standard
Smalltalk Message expression, problem solved.
to illustrate... using the SMaCC grammar of the NewCompiler (a bit
simplified) as extendend for Pragmas, Primitives and FFI by
Mathiue Suen.
A method in Squeak has Pragmas:
Method:
| MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:};
So they are difined like this (we can have multiple ones):
Pragmas:
PragmaMessage
{#pragma:}
| Pragmas PragmaMessage
{#pragmas:}
So it's quite simple: there is one message expression inside... simple. But
there is FFI. Primitives are
there, too, but that's not really a problem: they fit in the Pragmas.
primitive: 15 is a valid message in Smalltalk.
(Math did the gramar for
Re: [Pharo-project] web services, pharo
On Sun, Feb 14, 2010 at 4:24 PM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
;)
BTW did you convert my old videos?
yes, sort of :
http://pharocasts.blogspot.com/2010/01/learn-smalltalk-with-profstef.html
Laurent
Stef
On Feb 14, 2010, at 1:20 PM, laurent laffont wrote:
Make sure that the stream is binary:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Adding a multi-threaded FFI interface is always feasible. What I'd suggest is some get their corporate sponsor to pay for it as part of building the Alien FFI plugin for Unix and Windows. Then gift it back to the community, otherwise you'll see zero movement. On 2010-02-14, at 4:42 AM, Mariano Martinez Peck wrote: I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. Cheers Mariano On Sun, Feb 14, 2010 at 11:44 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only I'm not knowledgeable enough but I refer here to some discussions I got with eliot when we were at amsterdam. The comments I heard on the FFI implementation were not that positive. Now may be there is a road for FFI and Alien and it would be good to have the extension lukas did in 3.9. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Well *cough* I've always wondered why we use a un-supported smalltalk based
decoder here versus relying on the
JPEGReadWriter2 which uses the JPEG libraries we bundle into the VMs. Maybe
you should to a quick performance test
and see how they compare?
On 2010-02-14, at 4:01 AM, laurent laffont wrote:
Arghh it's almost done but I have a bug:
SketchMorph fromStream:
('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents readStream)
fails: image format is not recognized.
In JPEGReadWriter class understandsImageFormat
aStream next = 16rFF answer false ???
- aStream next answers a Character instance
- 16rFF is a SmallInteger
- both equals 255.
What is the right way to correct that ?
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
laurent have a look in the network chapter of the new blue book (collective
book available on web page)
because I do not remember but you could find some snippets going in the same
sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
===
John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.0] #10510
10510 - Issue 1788: SMTPClient does not send HELO or EHLO, session is not initiated Issue 1953: Network: smtp should send helo first -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11209
11209 - Issue 1953: Network: smtp should send helo first -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Thanks for help and enjoy :)
http://pharocasts.blogspot.com/2010/02/rest-xml-parsing-and-photos.html
Laurent Laffont
On Sun, Feb 14, 2010 at 1:20 PM, laurent laffont
laurent.laff...@gmail.comwrote:
Make sure that the stream is binary:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in
the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
Incredible. Clap clap clap!
Let me say that I really like your screencast and every time I see them, I
learn. I think that we really should have a link from the official pharo
website to your blog.
Little note just in case you didn't know. To TAB right or left several
rows/lines, just select them and use the shortcuts ctrl + shift + r (to tab
right) or ctrl + shit + l (to tab left) :)
Cheers
Mariano
2010/2/14 laurent laffont laurent.laff...@gmail.com
Thanks for help and enjoy :)
http://pharocasts.blogspot.com/2010/02/rest-xml-parsing-and-photos.html
Laurent Laffont
On Sun, Feb 14, 2010 at 1:20 PM, laurent laffont
laurent.laff...@gmail.com wrote:
Make sure that the stream is binary:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in
the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 1884: NetNameResolver doesn't work in PharoCore
http://code.google.com/p/pharo/issues/detail?id=1884 This issue probably is the last obstacle for the 1.0 release. I've added the following comment: - The preference proposed by Miguel does not solve the problem but puts the burden on the user that needs to change the preference depending on which implementation works for him. This will lead to many questions and frustrated users. If possible, I'd prefer to make the legacy IPv4 implementation work again until we have a proper IPv6 implementation. The problem with printing NetNameResolver addressForName: 'www.yahoo.com' is not that the resolution does not work correctly but that the printOn: implementation of SocketAddress assumes an IPv6 address. I suggest to change the SocketAddressprintOn: as follows. Maybe it's just this simple change to makes IPv4 work again -- maybe more such backward compatibility code is needed. SocketAddress printOn: aStream NetNameResolver useOldNetwork ifTrue: [ ^ super printOn: aStream ]. aStream nextPutAll: self hostNumber; nextPut: $(; nextPutAll: self hostName; nextPut: $); nextPut: $,; nextPutAll: self serviceNumber; nextPut: $(; nextPutAll: self serviceName; nextPut: $) - This change makes #addressForName: work again with useOldNetwork set to true (as it is in recent PharoCore 1.0 images). Could people that experience problems with the network code update this method and check out if other parts break? Cheers, Adrian ___ http://www.adrian-lienhard.ch/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HelpSystem implementation
Hi Danny,
- What is the reason to have HelpBuilder and to create a hierarchy of
HelpTopic instances mirroring the layout of the actual content classes?
Why
not use the class objects directly?
HelpBuilder builds the topics/books from code. I just wanted to decouple
the storage mechanism (here ST source code). Topics/books could also
be stored in an external database/files or even created on the fly from
dynamic information.
- Why do you use pragmas for the titles of the pages? If I understand
correctly, pragmas are for metadata of methods, but it seems to me that
the
title of a page belongs to its data just as much as its contents do.
Did'nt like
firstPage
^#{'First Page Title' 'Contents'}
No other reason. Or we return a dictionary in #pages?
Would this be better?
Bye
T.
--
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] 16rff broke 16r8e7
As you may know, with 16rff change, we cannot anymore use a radix notation combined with an exponent notation. At least for base 14, the exponent letter is taken as an ordinary digit. The options are: 1) revert the change 2) abandon combined radix+exponent notation all the code for printing Float with different radix, and also for scanning can be removed Or I can provide a subclass of SqNumberParser for backward compatibility. 3) find a new syntax for radix+exponent For example, 16r7f_e6 16r7f^6 16r7f#6 None of these is ambiguous with existing code. Or maybe use an uppercase R for uppercase only digits... 4) use q exponent to at least enable base 16 This is hackish and not universal, but I guess hardly anybody ever used a base 16. - What would squeak/pharo folks choose ? - Personnally, I'm OK with 1) and 2). But 2) deserves a bit more discussion After all this is a change of Squeak syntax. I find Dan's notation educative and fun, especially for writing tests. But it is a non portable Squeakish thing, rarely used, and it does not really has much value for industrial usage, On the other hand, is it really necessary to parse 16rff ? I dislike 3) because I find my own propositions bad. Also, if we remove Squeak-specific syntax for compatibility reasons, why the hell adding a new uncompatible syntax? Previous usage of e notation was far better because just extending an existing syntax, not creating a new one. Maybe you'll have other ideas... Nicolas - ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
2010/2/14 Mariano Martinez Peck marianop...@gmail.com
Incredible. Clap clap clap!
^o^
Let me say that I really like your screencast and every time I see them, I
learn.
Me too while recording :) I hope other people will contribute
I think that we really should have a link from the official pharo website
to your blog.
There's one here: http://pharo-project.org/documentation/tutorials-books
Little note just in case you didn't know. To TAB right or left several
rows/lines, just select them and use the shortcuts ctrl + shift + r (to tab
right) or ctrl + shit + l (to tab left) :)
Cool, thank you. I hope shortcut assignment will be better in 1.1
Laurent Laffont
Cheers
Mariano
2010/2/14 laurent laffont laurent.laff...@gmail.com
Thanks for help and enjoy :)
http://pharocasts.blogspot.com/2010/02/rest-xml-parsing-and-photos.html
Laurent Laffont
On Sun, Feb 14, 2010 at 1:20 PM, laurent laffont
laurent.laff...@gmail.com wrote:
Make sure that the stream is binary:
SketchMorph fromStream: ('
http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in
the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 16rff broke 16r8e7
As you may know, with 16rff change, we cannot anymore use a radix notation combined with an exponent notation. At least for base 14, the exponent letter is taken as an ordinary digit. do you know how this is handled in VW? Stef The options are: 1) revert the change 2) abandon combined radix+exponent notation all the code for printing Float with different radix, and also for scanning can be removed Or I can provide a subclass of SqNumberParser for backward compatibility. 3) find a new syntax for radix+exponent For example, 16r7f_e6 16r7f^6 16r7f#6 None of these is ambiguous with existing code. Or maybe use an uppercase R for uppercase only digits... 4) use q exponent to at least enable base 16 This is hackish and not universal, but I guess hardly anybody ever used a base 16. what would be the example - What would squeak/pharo folks choose ? - Personnally, I'm OK with 1) and 2). But 2) deserves a bit more discussion After all this is a change of Squeak syntax. I find Dan's notation educative and fun, especially for writing tests. But it is a non portable Squeakish thing, rarely used, and it does not really has much value for industrial usage, I read the mail than juan mentioned but I could not understand or I read another one :) On the other hand, is it really necessary to parse 16rff ? sounds like? I dislike 3) because I find my own propositions bad. Also, if we remove Squeak-specific syntax for compatibility reasons, why the hell adding a new uncompatible syntax? Yes what does our wonderful ANSI standard mentions? Previous usage of e notation was far better because just extending an existing syntax, not creating a new one. Maybe you'll have other ideas... Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] issue 1499 in PharoDev 1.0 ???
Hi Frederic. I was looking for the packages to next PharoDev and I noticed to commited a new version of NewInspector (NewInspector-FredericPluquet.57) Do you know if this also work in 1.0 so that I can include the fix ? Thanks Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 16rff broke 16r8e7
On Sun, 14 Feb 2010, Nicolas Cellier wrote: As you may know, with 16rff change, we cannot anymore use a radix notation combined with an exponent notation. At least for base 14, the exponent letter is taken as an ordinary digit. The options are: 1) revert the change 2) abandon combined radix+exponent notation all the code for printing Float with different radix, and also for scanning can be removed Or I can provide a subclass of SqNumberParser for backward compatibility. 3) find a new syntax for radix+exponent For example, 16r7f_e6 16r7f^6 16r7f#6 None of these is ambiguous with existing code. Or maybe use an uppercase R for uppercase only digits... 4) use q exponent to at least enable base 16 This is hackish and not universal, but I guess hardly anybody ever used a base 16. - What would squeak/pharo folks choose ? - Personnally, I'm OK with 1) and 2). But 2) deserves a bit more discussion After all this is a change of Squeak syntax. I find Dan's notation educative and fun, especially for writing tests. But it is a non portable Squeakish thing, rarely used, and it does not really has much value for industrial usage, On the other hand, is it really necessary to parse 16rff ? I dislike 3) because I find my own propositions bad. Also, if we remove Squeak-specific syntax for compatibility reasons, why the hell adding a new uncompatible syntax? Previous usage of e notation was far better because just extending an existing syntax, not creating a new one. Maybe you'll have other ideas... I'd go for 1). Squeak extends the ANSI standard one way, while VW does in another. If you want portable code, use the standard compatible syntax: 16rFF. 2) is acceptable, but I wouldn't do it. Levente Nicolas - ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 16rff broke 16r8e7
I'd go for 1). Squeak extends the ANSI standard one way, while VW does in another. If you want portable code, use the standard compatible syntax: 16rFF. probably. at least digitValue: was fixed in the process. 2) is acceptable, but I wouldn't do it. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 16rff broke 16r8e7
2010/2/14 Stéphane Ducasse stephane.duca...@inria.fr: As you may know, with 16rff change, we cannot anymore use a radix notation combined with an exponent notation. At least for base 14, the exponent letter is taken as an ordinary digit. do you know how this is handled in VW? Stef 16rff is accepted 2r1e31 raise an Error explicitely stating exponent can't be mixed with radix in VW The options are: 1) revert the change 2) abandon combined radix+exponent notation all the code for printing Float with different radix, and also for scanning can be removed Or I can provide a subclass of SqNumberParser for backward compatibility. 3) find a new syntax for radix+exponent For example, 16r7f_e6 16r7f^6 16r7f#6 None of these is ambiguous with existing code. Or maybe use an uppercase R for uppercase only digits... 4) use q exponent to at least enable base 16 This is hackish and not universal, but I guess hardly anybody ever used a base 16. what would be the example 16r7Fq6 - What would squeak/pharo folks choose ? - Personnally, I'm OK with 1) and 2). But 2) deserves a bit more discussion After all this is a change of Squeak syntax. I find Dan's notation educative and fun, especially for writing tests. But it is a non portable Squeakish thing, rarely used, and it does not really has much value for industrial usage, I read the mail than juan mentioned but I could not understand or I read another one :) He has preserved Dan's extension. 16rff forbidden 16r7Fe6 = 16r7F00 On the other hand, is it really necessary to parse 16rff ? sounds like? I dislike 3) because I find my own propositions bad. Also, if we remove Squeak-specific syntax for compatibility reasons, why the hell adding a new uncompatible syntax? Yes what does our wonderful ANSI standard mentions? Base 2 to 36 with letter A to Z. Nothing about a-z. But nothing against it. In the rationale, 10e10 is not allowed (Squeak), nor 1.0q (VW) Previous usage of e notation was far better because just extending an existing syntax, not creating a new one. Maybe you'll have other ideas... Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] web services, pharo
I really like the idea of scripting and gluing together behavior.
What I would love to be able to do is to
use the webcam of my machine to scan a book ISBN number
and fetch all the data from a given provider.
Does anybody have an idea how we could plug all that together.
Stef
On Feb 14, 2010, at 8:45 PM, laurent laffont wrote:
Thanks for help and enjoy :)
http://pharocasts.blogspot.com/2010/02/rest-xml-parsing-and-photos.html
Laurent Laffont
On Sun, Feb 14, 2010 at 1:20 PM, laurent laffont laurent.laff...@gmail.com
wrote:
Make sure that the stream is binary:
SketchMorph fromStream:
('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/A1A/jySYN6rz_pc/DSC00801.JPG'
asUrl retrieveContents contents asByteArray readStream)
Levente
It works ! Thank you ! You've just saved a screencast :)
Laurent Laffont
Laurent Laffont
2010/2/13 Mariano Martinez Peck marianop...@gmail.com
I think he talks about this one
http://coweb.cc.gatech.edu/squeakbook/
2010/2/13 laurent laffont laurent.laff...@gmail.com
Which web page ?
Laurent Laffont
On Sat, Feb 13, 2010 at 3:42 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
laurent have a look in the network chapter of the new blue book
(collective book available on web page)
because I do not remember but you could find some snippets going in the
same sense.
Stef
On Feb 13, 2010, at 3:29 PM, laurent laffont wrote:
(SketchMorph fromStream:
('http://code.google.com/p/pharo/logo'
asUrl retrieveContents contentStream)) openInWorld
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 16rff broke 16r8e7
On Sun, 14 Feb 2010, Nicolas Cellier wrote: 2010/2/14 Stéphane Ducasse stephane.duca...@inria.fr: what does our wonderful ANSI standard mentions? Base 2 to 36 with letter A to Z. Nothing about a-z. But nothing against it. At 3.5.6 the BNF allows only uppercase letters (uppercaseAlphabetic). Lowercase letters are not valid. Levente In the rationale, 10e10 is not allowed (Squeak), nor 1.0q (VW) Previous usage of e notation was far better because just extending an existing syntax, not creating a new one. Maybe you'll have other ideas... Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore
On Sun, Feb 14, 2010 at 10:09 PM, Yanni Chiu ya...@rogers.com wrote: The last word on Metacello, that I recall reading in this list, is that it is an experiment. Has that changed? I'm happy enough to changed my habits, if that is the case. Metacello seems to be very stable, not an experiment any more. There are a lot of big projects that are being managed with it such us Moose, GLASS, PharoDev images, etc. Take a look to http://www.squeaksource.com/MetacelloRepository for all the available configurations. Nevertheless, Metacello hasn't released the 1.0 stable version. It is still in beta state, but I think the 1.0 will be very soon. In this case, my build script was loading Albatross, which had the dependency on FFI (so I was not directly interested in FFI). The script I had was pieced together somehow, long ago, and was using #loadFFI, which worked fine until a few days ago. BTW, since all FFI-Examples packages were removed from the FFI repository, even Metacello versions would fail because the package is no longer there. Thank for the report. I have just commited a new version that fix this and another couple of things. Can you tell me if it works ok for you ? Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ((Smalltalk at: #ConfigurationOfFFI) project version: '1.0') load. I have one failing test :( testUlongRange -- Yanni Stéphane Ducasse wrote: did you check the configurationOfFFI ??? Does it exist? Stef On Feb 14, 2010, at 7:45 AM, Yanni Chiu wrote: Oops, this was on Pharo. I just checked Squeak3.11-9371-alpha.zip, and ScriptLoaderloadFFI does not exist there. Anyhow, what is the proper way to load FFI? Yanni Chiu wrote: ScriptLoader loadFFI now fails because the package FFI-Examples is no longer in the repository. Does ScriptLoader need to be updated, or was the package deleted accidentally? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore
On Sun, Feb 14, 2010 at 11:04 PM, Mariano Martinez Peck marianop...@gmail.com wrote: On Sun, Feb 14, 2010 at 10:09 PM, Yanni Chiu ya...@rogers.com wrote: The last word on Metacello, that I recall reading in this list, is that it is an experiment. Has that changed? I'm happy enough to changed my habits, if that is the case. Metacello seems to be very stable, not an experiment any more. There are a lot of big projects that are being managed with it such us Moose, GLASS, PharoDev images, etc. Take a look to http://www.squeaksource.com/MetacelloRepository for all the available configurations. Nevertheless, Metacello hasn't released the 1.0 stable version. It is still in beta state, but I think the 1.0 will be very soon. In this case, my build script was loading Albatross, which had the dependency on FFI (so I was not directly interested in FFI). The script I had was pieced together somehow, long ago, and was using #loadFFI, which worked fine until a few days ago. BTW, since all FFI-Examples packages were removed from the FFI repository, even Metacello versions would fail because the package is no longer there. Thank for the report. I have just commited a new version that fix this and another couple of things. Can you tell me if it works ok for you ? Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ((Smalltalk at: #ConfigurationOfFFI) project version: '1.0') load. Sorry, It is this: ((Smalltalk at: #ConfigurationOfFFI) project version: '1.2') load. I have one failing test :( testUlongRange -- Yanni Stéphane Ducasse wrote: did you check the configurationOfFFI ??? Does it exist? Stef On Feb 14, 2010, at 7:45 AM, Yanni Chiu wrote: Oops, this was on Pharo. I just checked Squeak3.11-9371-alpha.zip, and ScriptLoaderloadFFI does not exist there. Anyhow, what is the proper way to load FFI? Yanni Chiu wrote: ScriptLoader loadFFI now fails because the package FFI-Examples is no longer in the repository. Does ScriptLoader need to be updated, or was the package deleted accidentally? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Cleaning included Monticello repositories in PharoCore
Hi folks: I was thinking that at least for the 1.0 release we should remove obsolete default repositories. I don't know if the word is default but I mean to those repositories that are already added when you download PharoCore 1.0 image. Those repositories are: 1) http://www.squeaksource.com/Pharo 2) http://www.squeaksource.com/PharoInbox 3) www.squeaksource.com/Installer 4) www.squeaksource.com/UIEnhancements 5) http://source.lukas-renggli.ch/flair 1) and 2) are ok. 3) I think we should remove it. 4) and 5) are there becuase Gofer and Polymorph are included in the Core image? What do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Failing ECUntypedModelTest testNarrowWith
Hi Lukas/Romain. While building a PharoDev, I noticed that ECUntypedModelTest testNarrowWith is failing. The problem is in: self assert: count 100. as count, which is equal to model entries size, is 98. Of course, if I change it to self assert: count 90. for example, it works prefect. I have no idea about this. What do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11210
11210 - Issue 1966: remove WordArray#bobsTest Issue 1965: remove squeakpages methods from ServerDirectory Issue 1958: refactor #definitionST80 Issue 1928: Remaining _ in comments Issue 669: Dependency between Morph-Kernel and FileList -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
Ok...if AlienFFI doesn't support multi-threaded, then, I think the same as Levente. Why should I use AlienFFI instead of the normal FFI ? Which advantages does Alien have? Does someone know ? (I ask just because of my ignorance) Because for the moment it has two disadvantages, the ones Levente said: only mac, only x86. Thanks Mariano 2010/2/14 John M McIntosh john...@smalltalkconsulting.com Adding a multi-threaded FFI interface is always feasible. What I'd suggest is some get their corporate sponsor to pay for it as part of building the Alien FFI plugin for Unix and Windows. Then gift it back to the community, otherwise you'll see zero movement. On 2010-02-14, at 4:42 AM, Mariano Martinez Peck wrote: I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. Cheers Mariano On Sun, Feb 14, 2010 at 11:44 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only I'm not knowledgeable enough but I refer here to some discussions I got with eliot when we were at amsterdam. The comments I heard on the FFI implementation were not that positive. Now may be there is a road for FFI and Alien and it would be good to have the extension lukas did in 3.9. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] HelpSystem (was ProfStef)
Thanks Torsten for the explanation. Much clear now. I really like the idea. On Sat, Feb 13, 2010 at 10:13 PM, Torsten Bergmann asta...@gmx.de wrote: I have implemented some authoring capabilities in ProfStefBrowser to create new tutorials Yes, authoring capabilities would be cool to have. But first we have to find out what the content really should be and how it should be represented (simple text, markup, active morphs, ...) Some kind of simple markup language to have for example links to other pages or books, or to execute code snippets with a single mouse click Do you know the Squeak welcome workspace? It provided something like this - a Text could define runs to change style, color of text or even have clickable links with Smalltalk code behind - dont know if this is still possible in Pharo since parts of Morphic are removed. On the other hand it was Squeak only - hard to create from tyical documentation formats (text, HTML, ...) Maybe we could reactive code from Scamper (the Squeak web browser) for simple HTML like text styling. Using a subset of HTML as description would also allow us to publish the help contents on webpages later. I also remember a full webbrowser written in Smalltalk (VW). Meanwhile it is open source (MIT), see [1] ... so lets just reactivate it ;) We all have many ideas (like yours with the debugger) - but first I would like to see a minimal version for a help system: - provide help contents as simple ascii text (as it is now) - ability to jump from a tool to a specific page (like F1-help on Windows) we can use a simple unique key which is defined in HelpTopic already. - ability to define order of pages together with order of (sub)books With a minimal help tool (included in the dev-image) we can provide help to beginners and start documenting Pharo. As a second step we can work on better markup, authoring, active content ... However - the repo is open for any contribution... NowIt is not clear for me the differences between HelpSystem and ProfStef. HelpSystem is like a normal help system you know from Eclipse, KDE, Windows, ... It is more a reference/documentation kind of thing. ProfStef is an interactive tutorial usefull to teach things step by step. Help system is new ? Yes, developed yesterday. should they be merged? Hey, we just decoupled ... why merge again ;) Read [2] when we should use one and when the other ? ProfStef is for an introduction (5min course) on Pharo or tools, an interactive tutorial to introduce Smalltalk or basic concepts. It is more workspace oriented. See Laurents comments. HelpSystem is more a general help system with a browser that should be available as a base framework so tools can provide help texts/contents to users. Bye T. [1] http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=trueprintTitle=Im_back..._but_SWS_isntentry=3364012145 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021782.html -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cleaning included Monticello repositories in PharoCore
Hi Mariano, I think that is a good idea. Just a note: Gofer is in: http://source.lukas-renggli.ch/gofer and not in: http://source.lukas-renggli.ch/flair Cheers, Doru On 14 Feb 2010, at 23:11, Mariano Martinez Peck wrote: Hi folks: I was thinking that at least for the 1.0 release we should remove obsolete default repositories. I don't know if the word is default but I mean to those repositories that are already added when you download PharoCore 1.0 image. Those repositories are: 1) http://www.squeaksource.com/Pharo 2) http://www.squeaksource.com/PharoInbox 3) www.squeaksource.com/Installer 4) www.squeaksource.com/UIEnhancements 5) http://source.lukas-renggli.ch/flair 1) and 2) are ok. 3) I think we should remove it. 4) and 5) are there becuase Gofer and Polymorph are included in the Core image? What do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Some battles are better lost than fought. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)
FFI is weak (nearly useless??) on callbacks, where Alien appears to provide good support. I agree the neither system is comlete w/o the ability to direct calls to an os thread to avoid blocking the entire vm. Bill From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Sunday, February 14, 2010 5:36 PM To: Pharo-project@lists.gforge.inria.fr; john...@smalltalkconsulting.com Subject: Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game) Ok...if AlienFFI doesn't support multi-threaded, then, I think the same as Levente. Why should I use AlienFFI instead of the normal FFI ? Which advantages does Alien have? Does someone know ? (I ask just because of my ignorance) Because for the moment it has two disadvantages, the ones Levente said: only mac, only x86. Thanks Mariano 2010/2/14 John M McIntosh john...@smalltalkconsulting.commailto:john...@smalltalkconsulting.com Adding a multi-threaded FFI interface is always feasible. What I'd suggest is some get their corporate sponsor to pay for it as part of building the Alien FFI plugin for Unix and Windows. Then gift it back to the community, otherwise you'll see zero movement. On 2010-02-14, at 4:42 AM, Mariano Martinez Peck wrote: I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. Cheers Mariano On Sun, Feb 14, 2010 at 11:44 AM, Stéphane Ducasse stephane.duca...@inria.frmailto:stephane.duca...@inria.fr wrote: Yes Alien is the way to go. I wonder why you think that. Alien is - mac only (you may say it's not true, because one could build a unix or windows vm that supports it, but that didn't happen in the past 1.5 years) - x86 only I'm not knowledgeable enough but I refer here to some discussions I got with eliot when we were at amsterdam. The comments I heard on the FFI implementation were not that positive. Now may be there is a road for FFI and Alien and it would be good to have the extension lukas did in 3.9. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.commailto:john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cleaning included Monticello repositories in PharoCore
If Gofer and Polymorph are included in the Core image ... wouldn't it make more sense for those to be moved to those Pharo repositories then? -- View this message in context: http://n4.nabble.com/Cleaning-included-Monticello-repositories-in-PharoCore-tp1555481p1555830.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Failing ECUntypedModelTest testNarrowWith
It is stupid to have tests that depend on what else is loaded in the image. OB and RB (for some parts) use a fake image with fake classes and methods in which they run their test. Lukas 2010/2/14 Mariano Martinez Peck marianop...@gmail.com: Hi Lukas/Romain. While building a PharoDev, I noticed that ECUntypedModelTest testNarrowWith is failing. The problem is in: self assert: count 100. as count, which is equal to model entries size, is 98. Of course, if I change it to self assert: count 90. for example, it works prefect. I have no idea about this. What do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cleaning included Monticello repositories in PharoCore
1) http://www.squeaksource.com/Pharo 2) http://www.squeaksource.com/PharoInbox 3) www.squeaksource.com/Installer 4) www.squeaksource.com/UIEnhancements 5) http://source.lukas-renggli.ch/flair I sugest to only keep 1 and 2. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
