[Pharo-project] Newspeak
Pharo is starting to look better and better, but not yet as good as Newspeak: http://newspeaklanguage.org/downloads/ Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Seaside29 broken on 10292 dev ?
Windows XPsp3, everything downloaded from the Pharo website WAKom startOn:8080 breaks with BlockClosure doesNotUnderstand #newProcesWithBindings: in HttpService start Lukas wrote; The very latest versions should work with closures. Some tests still fail, thats a bug in the Seaside tests though. On Friday, April 24, 2009, Stephan Eggermont step...@stack.nl wrote: How am I supposed to load Seaside into the latest 10292-dev? On windows I ?downloaded ?from www.pharo-project.org/download the vm, sources and dev image. ScriptLoader loadSeaside29 WAKom startOn:8080 that last one has a missing method on BlockContext that should be BlockClosure ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Seaside29 on 10292-dev
Thank you Lukas, Harvested as Issue 771 Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Questions: PDFs
On the seaside site, there is an overview I collected with Lukas last ESUG http://www.seaside.st/documentation/pdfs Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Questions: PDFs
Stefan Schmiedl wrote: http://www.seaside.st/documentation/pdfs Is it just me or are the LaTeX samples lacking backslashes? Thanks for a valuable overview, You're right, they should have backslashes. Probably a conversion problem. Andreas Brodbeck writes about another solution: http://andreas.mindclue.ch/blog/seaside+project+live Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Iso-Collections
Guido Stepken wrote: LSWVST introduces a new object-type - IsoCollections. Iso-Collections stores type information of its elements only once. That's nice, but not enough. Collections with more than a few thousand elements should use multiple blocks of memory (e.g. btree) to have acceptable insert performance. Hmmm, opening a simple Array of 1.000.000 elements consumes 4 megabytes in Pharo ... The point being? In a 64bit environment it will be 8MB. Only for bit/ byte sets or compressed collections it will be less. Cheap pc's currently have up to 16GB of memory, so the first 2.000.000.000 elements are no problem. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Dictionary use in SmartRefStream
While taking a look at Seaside issue 262 I noticed that SmartRefStreamcatalogValues: instVarList size: varsOnDisk creates a Dictionary with the default size, while having a pretty good idea of how large it should at least be. Is this called so little that that it doesn't matter?(it is only called in SmartRefStreamreadInsanceSize:clsname:refPosn:) Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] How to test SmartRefStream?
Transcript show:
[ |buffer rr book stream|
buffer := (ByteString new: 2000).
stream := (RWBinaryOrTextStream on:buffer).
rr := SmartRefStream on: stream.
rr nextPut: (Morph new). need something complicated
rr close.
2
timesRepeat: [
stream := RWBinaryOrTextStream with: buffer.
stream reset.
book := stream fileInObjectAndCode.
]] timeToRun asString.
Transcript cr.
gives me in the transcript:
(
is Undeclared)
(
[Pharo-project] Testing SmartRefStream...
Creates a lot of newlines on the mailing list. Sorry about that. My mail program didn't show the charactres at all. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Usability improvements for the class browser: buttons
Hello, When I open a class browser in a Pharo Image (10418 updated to 10451) with the default Watery 2 theme, the window is visually dominated by the button bar. Compared to the other parts of the window, it has too much vertical height and there is not enough white space around the buttons. The problem with vertical height can be illustrated by looking at the precision needed to select a class category versus that needed to click the browse button. The button has about twice the vertical height. That would be ok when clicking the button would be the more common operation, but I don't find that to be the case. The kind of button used in Watery 2 only works well visually when it has a rather large white space around it. The button bar of the preference browser already works much better than that of the class browser, but even that has too little space above and below. The buttons in the button bar of the class browser feel very heavy because they don't have enough horizontal separation. With the default window size, there is not enough space for the needed separation. When the window is grown, instead of growing the separation first, and then the button width, only the button width is grown. Some operating systems have introduced a better solution for this problem, a dedicated button bar. Attached is an impression of how this could look. I hope you'd agree that it would provide a cleaner look. I'd be interested in some clues on what would be needed to add such a button bar. The red, orange, and green window buttons used to have a much better horizontal separation. I am not sure in which update they were put so close together, but they need at least as much horizontal separation as the space from left window border to the first (red) button. Stephan Eggermont inline: ButtonBar2.png ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] anyone think buttons still too large?
From: empty empt...@googlegroups.com I tried to install version 1 rc to find the buttons still too large. If you look at the whole class browser the first things you see are those big blue buttons. I'd prefer they not so big and colorful. Anyone have the same feel? Yes, I even played around with a painting tool and started digging around in Toolbuilder, OmniBrowser and PolyMorph. Let me just say that I really, really, really like Glamour. See issue 909 Stephan Eggermont inline: ButtonBar2.png ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About end of line convention
Stéphane Ducasse wrote: When we edit a file we should be in control about that we want to have. I don't think so. What we want is an end of line. I don't care how it is represented. (Actually, I do. It should be out-of-band instead of a character. But I'm not going to get that). Only when saving/exporting (and importing) can I be interested in the representation. Default should be platform, as most people are not interested in implementation problems. In CUIS when you edit a file you can decide the convention or change it. I don't like that. It is fine for a hex editor, but not for text. Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo and db support
Doru wrote: I would like to collect a list of the solutions to link Pharo with existing databases. I am interested in both relational and in object databases. Something like http://www.seaside.st/documentation/persistence? Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse
Adrian wrote: What about using a wiki to gather and edit comments (as suggested by Stan) and then integrate them in a second step so that they are kept together with the code (as suggested by Stef)? Just a thought... I'd very much prefer an in-image solution and avoid integrating. In-image we have much better version info, and much better browsing available. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Date fromString: '6-Jan-10'
The real life situation with date strings is much worse. I live in a city (Zoetermeer) where a passport was issued with the holders birthdate being 00-00-1972. I'm very much in favor of not trying to be clever in the core Date classes, and to provide separate guessing logic, properly internationalized. The current readFrom: is not usefull at all, except in the US. And even there it simply breaks on real-life data. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] databases
Hello Laurent, I assume you are aware of: http://www.seaside.st/documentation/persistence Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] databases
Levente wrote in response to my: 3. You have a legacy (relational) database, with extensive reporting written for it. Use an ORM. Relational databases are not legacy, they have features which modern key-value stores don't (and won't). ORMs may ease the programmer's work, but they tend to have bad runtime performance and can't use (all) the features of todays RDBMSs. In creating the list of different scenarios, I tried to explain in a short text that different needs lead to different solution strategies. Legacy in this context refers to having an existing database you want to continue using. That is a situation where I would recommend starting with ORM unless it is shown that the run-time performance is going to be prohibitive. Please keep in mind that it is a text written for people new to Seaside (and possibly Smalltalk). If you have a suggestion for a better text, please mail me. Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] collections
Levente wrote: How bad do they perform? Do you have benchmarks? With a coll := OrderedCollection new. 1 to: 1000 do: [:i | coll add: i]. a profile of: 1 to: 100 do: [:i | coll add: i beforeIndex: 10] here takes 1438 ms. Moving memory gets to be slow. All operations that start taking O(#elements) time are no longer funny. The usual thing to do is to start using multiple blocks of memory (like a BTree). Doubling size when growing is also not an acceptable strategy when getting close to total ram capacity. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Igor wrote: Yes. Use right tool for to do job. An OrderedCollection can't satisfy every possible combination of tasks, which developer facing. So, these collections are currently missing. And as all current code is bound to the current implementations, switching implementation on size is the prefered approach. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Igor wrote: If such kind of collections didn't existed over more than 30 years of smalltalk existance, what makes you think that there a big interest in having them today? Memory. Without the memory to use them, the need was not there. Of course, they could occupy some niche, but i doubt that they will replace an existing classes in a day-to-day use. In a 64 bit system, it is not a niche. You simply need a set of collection classes that work well with millions an tens of millions of elements, not just 100.000s. Besides, many projects implementing own kinds of collections, specific to their needs. That is exactly what you want to avoid. I've had to implement these collections too often. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Levente wrote: Trees are rarely useful in Smalltalk, so there's no default tree implementation. Note that trees consume a lot more memory (=5x) than a single array. Huh? You mean binary trees? Or Red-Black or so? On current procesors they are not very useful, and not usable at all for large data structures because of the large overhead. But n-ary trees or two-level stuctures are. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Igor wrote: What you talking about is an edge case in currently existing systems. And its easy to prove: That's not convincing. I'd say you have cause and effect reversed. I'd not expect there to be large OrderedCollections as long as they don't behave well. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Trip to Pharo land
I'd guess the important thing is to explain on the Pharo web site that bug fixes are in the 1.1 and are not (always) retrofitted to 1.0 Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo sprint @ Brussels
I'll be there on Saturday. Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Cloud vs object
Germán wrote: Anyway I personally largely prefer the objects databases :) But indeed these sort of DBs (as Cassandra) are being more and more populars, I think that this is mainly for its HA features. I tend to run into applications where it makes sense to have both. The big blobs that do not change a lot (photos, documents) in the cloud, the objects with behaviour in the oodb. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Suggestions for hotel/apartment for ESUG2010 in Barcelona?
Does anyone have suggestions for a good (and cheap) place to stay during ESUG2010 in Barcelona? The conference is not in the city centre, and the only hotel which is close by (NH Cornellà) has no places available. We thought of renting a large appartment somewhere along the metro line 5 and sharing. Anyone interested? Stephan Diego ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Poll: missing libraries to support business
Philippe wrote: Rather than imagining what problems non-users could have I'd focus on what problems existing users have. Instead of building libraries that you'll have to maintain forever I'd focus in infrastructure that allows users to write the libraries they need themselves. Executive summary: - HTTP(S) - SqueakDBX - VM/Cog/kernel/FFI/Alien - making it possible to use all the memory in my system: 64 bit. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Gaucho Progress
Gaucho looks like an interesting system. Too bad the monticello versions don't have comments, making it difficult to track progress. Is there another way to see what's happening? Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Moose-dev] glamorous theme :)
Sven wrote: Sorry: if you switch to the Pro theme The example basic controls shows the following issues: - Default button looks smaller because the blue border is (imperfectly) written over the black outline. - Selected Disabled Button is unreadable. The contrast between the gray text and the blue background is too low. It could be improved by using outline style. - The gradient is blue is much stronger than that in black. I would say the black needs more lights. The buttons contrast too much with the light gray background. - The disabled checkbox misses a line at the top - Borders of button, checkbox and radiobutton should look similarly sharp. Now the button looks sharp, while the others look blurry. The same goes for drop lists, normal lists and text editor. - Vertical spacing between the radiobuttons is inconsistent. - Text Entry looks like it has more height when disabled. This is due to the top gradient of the non-disabled one. - Disabled slider handle is too dark. - Backgound color for Text Entry, Slider, List (s) and Text editor should be the same for disabled state. The same goes for disabled text foreground color. Why has disabled drop list a different text color than a disabled text entry? - Lists should have the same corner as text entry. - Drop list button has the V a-symmetrical. - Difference between normal list and disabled list is too small. - The border between scroll bar buttons and light gray background is not enough pronounced. Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [Moose-dev] glamorous theme :)
Hello Doru, Doru wrote: Is this for Pro or for Glamorous? I was refering to: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100905/21e9b4c2/attachment-0001.png That makes it for pro. But a lot of the issues are for both. In Laurents screenshot there are also alignment issues for checkbox and radiobutton. Disabled text should not have both less and more contrast (label vs text entry) Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [Moose-dev] glamorous theme :)
Sven wrote: I would include a small number of well maintained/supported themes. Of course, every image needs a default, but choice is good here (it is the whole point). This is something I have to disagree strongly with. Choice in themes does not work for us. We don't have the manpower to maintain them. In user interfaces, consistency is good, and I want one good theme, not ten bad or mediocre. Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] posting etiquette - please post new text at the *top* of your email
Niko wrote: I think RFC1855-style messages still look beautiful, and they have their place. But if you're too lazy to follow the gist of it, that's alright with me, but then put your content at the top, so I don't have to scroll down to Walhalla. The best thing to do is to make the mailing list enforce trimming and quote- to original text fraction and reject top- and bottom-posts. It tends to have a very good effect on readability of the list especially when looking back a few months/years later. Stephan
[Pharo-project] Not happy with the issues feed from Google
Hello, I'm not happy to see the feed subscribed to this mailing list. I often have to use the web interface to this list, and the number of one-line comments and status changes makes for a very unpleasant reading experience. In addition it makes it more difficult to find the interesting discussions. As a workflow, it also has problems, as reply mails are not added back to the issue tracker. Stephan
Re: [Pharo-project] Not happy with the issues feed from Google
Mariano wrote: Remember that most email client support filters. You can easily create one. - That doesn't help with the web interface; - My mail client supports RSS feeds, the added value of a duplicate is low; - Filtering doesn't work with digests; - The subject is not good and the content is not good for a mailing list; - It reduces the searchability/usability of the mailing list archives; Stephan
Re: [Pharo-project] Not happy with the issues feed from Google
Stef wrote in reply to: On Nov 18, 2010, at 5:53 PM, Stephan Eggermont wrote: That doesn't help with the web interface; ?? As I said, I often browse http://lists.gforge.inria.fr/pipermail/pharo-project/2010-November/ But you just get a bad summary from squeak-source I have to click on the link all the time. But then you at least get to see the whole discussion instead of one line. - Filtering doesn't work with digests; I do not understand The mailing list has a digest function. Most email clients do not know how to filter them. - The subject is not good and the content is not good for a mailing list; Why Bugs are our concerns I fully agree that bugs are our concern, and that it is important to make activity visible. I also understand and share your frustration that bug reports are badly read and written. I just think that this works contra-productive. - the subject of a feed message is bad: it is just the issue number and the issue title, instead of adding what happened with the issue. - the content of a feed message is bad: the context is missing. - It reduces the searchability/usability of the mailing list archives; Why? I want to look for bug discussions there too and not using a bad google search engine. I think the problem most potential contributors have is one of too much information, not too little. Giving them more, in a badly prepared format, is unlikely to help. Stephan
[Pharo-project] Revisiting Issue 1718
I would be interested in improvements. This is just a straight translation of the java code. Yaroslavskiy's Dual-Pivot Quicksort seems to perform better for large collections: A straightforward defaultSort: i to: j self dualPivotQuicksort: i to: j split: 3 dualPivotQuicksort: left to: right split: div |len third m1 m2 pivot1 pivot2 less great dist newDiv| len := right - left. newDiv := div. len 27 ifTrue: [ left+1 to: right do: [ :i | | j | j := i. [(jleft) and: [(array at:j) (array at: (j-1))]] whileTrue: [ array swap: j with: j-1. j := j-1]]] ifFalse: [ third := len // div. m1 := left+third. m2 := right-third. m1 = left ifTrue: [m1 := left+1]. m2 = right ifTrue: [m2 := right-1]. (array at: m1) (array at: m2) ifTrue: [ array swap: m1 with: left. array swap: m2 with: right] ifFalse: [ array swap: m1 with: right. array swap: m2 with: left]. pivot1 := array at: left. pivot2 := array at: right. less := left+1. great := right-1. less to: great do: [ :k | (array at: k) pivot1 ifTrue: [ array swap: k with: less. less := less+1.] ifFalse: [ (array at: k ) pivot2 ifTrue: [ [(k great and: [(array at: great) pivot2])] whileTrue: [ great := great -1]. array swap: k with: great. great := great-1. (array at: k) pivot1 ifTrue: [ array swap: k with: less. less := less+1] ] ]]. dist := great-less. dist 13 ifTrue: [ newDiv := div+1]. array swap: (less-1) with: left. array swap: (great+1) with: right. self dualPivotQuicksort: left to: (less-2) split: newDiv. self dualPivotQuicksort: (great+2) to: right split: newDiv. (dist (len -13) and: [ pivot1 ~= pivot2]) ifTrue:[ less to: great do: [ :k | (array at: k) = pivot1 ifTrue: [ array swap: k with: less. less := less+1] ifFalse: [ (array at: k) = pivot2 ifTrue: [ array swap: k with: great. great := great - 1. (array at: k) = pivot1 ifTrue: [ array swap: k with: less. less := less+1] ] ] ] ]. pivot1 pivot2 ifTrue: [ self dualPivotQuicksort: less to: great split: newDiv] ] Do we have a performance test set for sorting?
[Pharo-project] Much better issues feed from Google
Would be to have it in a browser in the image. An early experiment with the current Moose daily build shows it can be done: http://www.squeaksource.com/GoogleIssuesFeed Stephan
Re: [Pharo-project] source.lukas-renggli.ch is down
Philippe wrote: On 29.12.2010 11:01, St?phane Ducasse wrote: We know. I will reask again for our web-dav server. You're actually working in a big bank, aren't you Stef? I can tell by the time it takes you to get a web-dav server ;-) No, in a bank they would have asked him why he needs his own Exchange server. Stephan
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (ph...@googlecode.com)
Nicolas wrote: Then group the selectors (first, first: etc..), explain that they are extensions, and don't need a copy prefix, because anyway most messages will do a copy. You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters). Stephan
[Pharo-project] Startup weekend success
In the weekend of 20 Feb. Diego Lont and I participated in Startup Weekend Eindhoven. As we expected, the rapid development made possible by the combination of Seaside on Pharo made it possible for us to develop a convincing demonstration in two days. The Parent Support app, an idea presented on friday night by Liesbeth Vriens, was converted by us into a combination iPhone app and web application in the two following days. This together with the business plan developed with Dolf Wittkämper were presented by Liesbeth on sunday evening in an award-winning 3-minute pitch. The jury awarded us the innovation price. Stephan Eggermont
Re: [Pharo-project] Pharo on Apple App Store
Hilaire Fernandes wrote: I read prediction Android may take it all. There are currently no signs of that. Stephen Elop (of Nokia) allegedly wrote In 2008, Apple’s market share in the $300+ price range was 25 percent; by 2010 it escalated to 61 percent. They are enjoying a tremendous growth trajectory with a 78 percent earnings growth year over year in Q4 2010. That means there can be large numbers of Android devices on the market, but at a very low price. That's killing the producers, instead of making them rich. Or to explain it differently: Apple's problem is getting enough devices out the door. Not the price. If they want more market share, they can simply introduce lower-priced models, unlike the Android producers. As long as the Android market is so shattered and so incapable of producing compelling alternatives, they wait. Do you know Inside the Tornado by Geoffrey A. Moore (you might know him from Crossing the Chasm). My version has a quote by the founder and CEO, NeXT Computer on the title page. Stephan
[Pharo-project] Fwd: Https Url in Pharo 1.2
Stef wrote: On Mar 6, 2011, at 8:39 AM, laurent laffont wrote: Is it planed / possible to have SqueakSSL plugin in official VM shipped with Pharo ? What is the license? You know the last time we got trapped into the game oh I did not decided yet so never again. What is the status? On squeaksource it is MIT, last update from jan. 12. Stephan
[Pharo-project] Meanwhile, at another vm
http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002802.html
Re: [Pharo-project] Meanwhile, at another vm
JSR 292 explicitly talks about become: (calls it hotswap) and is supposed to make it possible to run Smalltalk efficiently on a jvm. I don't know how complete the jsr 292 implementation is of mlvm. I got the link in a tweet. Roos builds modular automated test equipment. Stephan
Re: [Pharo-project] [ANN] new mailinglist for tracker mails
Marcus wrote: The mails from the google tracker now go to this list: http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker in turn, this means the traffic on the pharo-project list should be a bit more managable. Thank you. Stephan
[Pharo-project] Hudson setup published?
Is the Hudson setup used to generate the Pharo images published? Last friday there were some issues that were not reproducible with the standard test-runner. Stephan
Re: [Pharo-project] Networking problems on Pharo 1.2.1
That is no networking problem. That is just how a tcp server connections work. When you connect from a client to the server, the server has to initialize a new socket to communicate on. Just take a look at what waitForConnectionFor does. Stephan
[Pharo-project] SandstoneDb test failure on Pharo 12353 Seaside image
SDFileStoreTests testFindAllSubclasses is broken in the CI Pharo 12353 Seaside image of 2011-5-25. SandstoneDbTests RamonLeon.10 SandstoneDb RamonLeon.138 Stephan Eggermont
Re: [Pharo-project] [GS/SS Beta] serializing object graphs / ordering graph anchors
Hello Norbert, That sounds like a silly algorithm. There is no reason you should get a large stack size as long as you don't try to do this more than one level deep only: add object to the table repeat find first unwritten object in the table write its contents: simple objects direct for a complex object: look it up in the table if it doesn't exist, add it to the table write its reference mark as written until no unwritten objects in the table Stephan On 2 jun 2011, at 12:38, Norbert Hartl wrote: Before I start a utility myself I want to ask if there is such a tool already. I'm using sixx for object graph serialization. It works quite good but it has some severe limits. Well, the limits are not really sixx dependent but a problem of usual serializers. My problem is the size of the stack such a tool generates. Especially in gemstone this appears to be a problem because the stack is limited per gem. If I look at the serializers I know the mechanics are simple: 1. take an object and look it up in a table. 2. if the object is in the table it has already been serialized. We take a reference from the table and write it down 3. if it isn't in the table it means the object has not been serialized and the contents need to be written. After that the object with a reference representation is written to the table 4. while writing the content of an object (inst vars) I encounter simple objects (direct string representation) or complex objects (composite). In the latter case we start over from 1. If the object graph is well interconnected than the odds are high that a stack will grow high until the first reference can be written. With a small pier kernel I already matched a stack size of 1000. One solution I can think of is to collect and order objects in the graph that cover smaller segments from the overall graph. This way I would construct a sorted collection that is sorted by stack depth (lowest first). The collection will then be serialized leading to a much smaller possible stack sizes. It might be there are cases it can't work but I think for most cases it will do its job. And it will be slow of course. Does anybody know if such a tool exists? Norbert
Re: [Pharo-project] Silly Tweet
Igor wrote: On 29 June 2011 15:56, Schwab,Wilhelm K bschwab at anest.ufl.edu wrote: Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server. Sounds great. Indeed. If people would like to use older releases, they should look for another place, not for build server. Since build server are there to build test bleeding-edge (under development) versions, but not ones which already released and years old. Ok, so you simply do not want the builds to be used by others. That's fine. Stephan Eggermont
Re: [Pharo-project] Silly Tweet
Stef wrote in response to my: Ok, so you simply do not want the builds to be used by others. That's fine. why do you say that? Such a build server can have two purposes: - to directly help with the development of the software named in the build jobs; - it can provide a starting point for others to base their work on. Both are valuable, and it is acceptable if you want to want to focus on the first. For the second, as a commercial developer I have to be able to make my upgrade schedule as independent as possible from that of the projects I depend on. Depending on artifacts with an unknown availability is not possible. What is the point to have a build server build all the time the same same same same same same same image? A build server is used as we've learned there is no such thing as the same same image. There have been regressions because of vm changes or operating system updates, and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside change. Stephan
Re: [Pharo-project] Interesting expression...
((para isKindOf: MultiNewParagraph) or: [para text string isByteString or: [para text string isWideString]]) If you want to be able to handle large texts with nice (LaTeX-like) line breaking we'll probably need some different String implementations. I don't know how far MultiNewParagraph scales. Stephan
Re: [Pharo-project] Storing all source code in a relational database
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model. Stephan
[Pharo-project] Fwd: [FOSDEM 2012] Devroom accepted: Smalltalk, Sunday 2012-2-5, Brussels
Dear Smalltalking Friends, Please tell me what you'd like to happen there. We have a good opportunity to show why we believe in smalltalk. I can do a 'Back to the future, (re)learning smalltalk' session. Stephan Begin forwarded message: From: Pascal Bleser pble...@fosdem.org Date: 10 november 2011 23:58:43 GMT+01:00 To: Stephan Eggermont step...@stack.nl Cc: devro...@fosdem.org Subject: [FOSDEM 2012] Devroom accepted: Smalltalk Reply-To: devro...@fosdem.org Hi Stephan We've got good news, as we have accepted and planned your request for a developer room at FOSDEM 2012 for the following topic/project: Smalltalk We will provide you with the following: - room AW1.126 with 72 seats, - a video projector (VGA) - wireless internet, on Sunday 5th for 8 hours. If you prefer to decline this offer, please inform us as soon as possible. We must add that as in previous years, visitor interest will outnumber room capacity for most devrooms. We can not offer you larger rooms -- instead we will provide you with signalization to indicate that the room is full. We will have more rooms in total as compared to previous editions, so hopefully that will balance the crowd across the various areas of the venue. Regarding content and format, you are free to schedule your devroom as you wish (presentations, discussions, brainstorming, workshops, BOFs, hacking sessions, ...). Do allow us to repeat the obvious: FOSDEM is a FOSS community event, by and for the community, and the content and topics _must_ reflect that (arguably, that is pretty obvious). It is also a technical conference, as our view is that the very broad spectrum of Free and open source projects should work together rather than fighting religious wars -- at least when at FOSDEM -- and we would like you to respect that, especially given the very diverse palette of projects that are present at the event. We invite you to send out an open call for talks to relevant mailinglists, including fos...@lists.fosdem.org. We will collect all call for talks and announce them on our website next week. We offer each of the devrooms a name-devr...@fosdem.org mailman mailinglist, in case you want to have a mailinglist on neutral grounds. This can be especially interesting for devrooms that aggregate several projects. Contact us at devro...@fosdem.org to take on this offer. We will most probably provide you with a tool (website) to send us the schedule containing all information necessary for the website and the booklet. More information on that later, as it is still work-in-progress. (Yeah, we said that last year too but it might actually work this time ;)) The hours listed above are the schedulable hours. We recommend to plan the first 15min or so with a little welcome talk so you can prepare the first real speaker (network, connect to video projector, etc...). We can also open the room a bit earlier for preparations. We expect the rooms to be empty 30 minutes after the last talk on your schedule, as we need to clean the rooms up and close them with the security staff. For stocking material overnight, we have a large room in the H building (Ferrer, next to the Infodesk) that will be locked from Saturday 18:00 to Sunday 09:00. However, there is no insurance whatsoever and we take no responsibility for stolen or damaged goods, even though there is a security team at the venue, including during the night. For us, you are the devroom responsible. This means that we will communicate everything through you, and you will be the one we will poke for information ;) Also, during the weekend, we want you to do good housekeeping of the room: - we will offer trash bags for the garbage, and we would very much welcome not finding garbage lying around in the room when you leave (simply draw the attention of the crowd in your devroom on that point on a regular basis), - there is a limit on the room capacity that may not be exceeded (by much) for obvious security reasons. Please understand that we are a non for profit association, and that every single organization team member works on FOSDEM during their spare time. As such, it would be very nice if we didn't have to spend several hours cleaning up the devrooms, and it is just a very small amount of work for the attendees to put their garbage into the trash bags. We will supply each room with a sufficient amount of the latter. The deadline for sending in the full schedule will be Saturday 2012-01-21, so we advise you to decide on the content by the turn of the year or earlier (earlier = more time for participants to book their arrangements for travel and stay). We don't do that to put you artificially under pressure but, instead, in order to have the complete schedule to present to visitors and on the various mobile applications for the FOSDEM schedule, as well as to include your devroom schedule into the booklet
Re: [Pharo-project] Java team looking into Smalltalk and Seaside
Sean P. DeNigris wrote: Maybe someone with experience using Smalltalk on a team can answer this: http://stackoverflow.com/questions/8244502/version-control-for-smalltalk-seaside Nice question. I've added a mixture of what we do and should be doing... Stephan
Re: [Pharo-project] experience with large images?
Francois Stephany wrote: I'm wondering: how big is a dataset 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB? We are doing data conversion with Moose. Raw data is 740 MB. No 64-bit means being forced to make decisions early, and therefore wrong. It also forces us to do some batch processing. We're very lucky the customer has a good idea on what data to keep. Stephan
Re: [Pharo-project] experience with large images?
Igor Stasenko wrote: I think you looking for solution in a wrong direction. Just ask yourself, how much of that data you need to keep in operative memory at single moment of time to efficiently compute results. All of it. And then of course the annotations and resulting output model. I know practically nothing about the data at first (about 700 files, about 700 MB). When trying to understand the data, it is crucial that I can test hypotheses fast. Efficiency is about my time, not computer time. If today you need to deal with 500Mb data sets, tomorrow you may need to deal with multigigabyte datasets, which can easily surpass the amount of operative memory your computer has. 16 GB DIMMS are about 250 Euro. For a commercial project it is easy to justify half a terabyte of ram. I know, it is easier to find cheap solution, without spending time implementing own data caching scheme, but you just delaying inevitable. Delaying is crucial. If I wait long enough, PC's will have enough memory. Stephan
Re: [Pharo-project] [Esug-list] fosdem smalltalk devroom
No, not yet. Do we need a separate one or can we use one of the existing ones? I'm following a.o. squeak-dev, pharo-dev, seaside Stephan On 28 nov 2011, at 12:37, Paolo Bonzini wrote: Hi all, is there a mailing list or website set up for discussing the program for the devroom? Thanks, Paolo ___ Esug-list mailing list esug-l...@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
[Pharo-project] Call for Participation in the Smalltalk Devroom at FOSDEM 2012.
Call for Participation in the Smalltalk Devroom at FOSDEM 2012. A devroom for the Pharo, Squeak, GST, Etoilé, Seaside, Moose Smalltalk projects. Smalltalk environments offer a very high development productivity, unmatched by their successors. Come do some pair programming with us and experience the advantages of a real OO environment. The meetup will take place Sunday, February 5, 2012, from 9AM until 5PM, room AW1.126. This room has 72 seats, a VGA video projector and wireless internet. More information will be available later. Proposals on content and format are welcome. People interested in running a session should announce that on the smalltalk-devroom mailing list, with the following information: - Their name - The project they are associated with - A short bio, to be put on the website along with their speaker name - (optionally) a picture of themselves - The title of their session (which will go on the website and in the booklet) - A abstract describing the session in further detail. - The desired length of the session. - The desired time slot in which they want to hold the session. Suggested values for the duration are 55min, 25min, 6m40 (Pecha Kucha). The desired time slot is meant to help you prevent conflicts with other dev rooms in which you might have a talk or your travel arrangements. The deadline for submissions is December 31, 23:00 GMT+1. Discussion takes place on the smalltalk-devr...@lists.fosdem.org mailing list. Please subscribe if you are interested: https://lists.fosdem.org/listinfo/smalltalk-devroom The local VUB/ULB Smalltalkers have been asked to organize a sprint/BSUG meeting on Saturday Februari 4. Devroom related URLs: http://www.pharo-project.org http://www.squeak.org/ http://etoileos.com/ http://www.seaside.st/ http://smalltalk.gnu.org/ Please distribute
Re: [Pharo-project] [ANN] Magma 1.3
Hi Chris, Great! I'd love to have someone explain and demo Magma at the FOSDEM2011 devroom (Feb 5, Brussels). You already told me you'd not be available. Anyone else capable willing to do a presentation? Stephan
Re: [Pharo-project] Company/freelance working with Pharo/Seaside
Sven wrote: Having an active community where many people participate in making Pharo better all the time is the best reference. While that is a necessity, it is only relevant for a certain public (technically advanced, developer oriented, long term view). It is not necessarily something other potential customers value. I'm currently doing a data conversion project. Everything outside a timespan of the next 6 months is simply irrelevant. Startups with a lack of deep technological knowledge also cannot tell the difference between a very large but clueless community and a small, but active and knowledgable. It is also important that success stories, even small ones, are shared. Very much so. And (also) in a form that less technical people can understand. But I guess that half the people on these lists are available for remotely delivered services in one form or another ;-) That seems like a correct observation. On the other hand these mailing lists function as a filter and are not a good way to match demand and supply. The problem is in explaining where Pharo/Seaside can provide a good solution in business terms. Although it is important that the community keeps on growing, we reached critical mass a long time ago, IMHO. For innovators yes. For early adopters, no. They value different things. Stephan
Re: [Pharo-project] glamour and pharo
There are a number of separate problems here, I think. Mixing them up makes the situation a bit complex. I'll try separating them here. At what abstraction level should the basic tools be build. From my point of view, Glamour provides the right level. It is very easy to build browsers and it is easy to keep them maintainable. When the underlying stack is going to be replaced it makes sense to have an abstraction layer that is is easy to implement on both the old and the new stack. The alternatives (Morphic, PolyMorph, OmniBrowser, ToolBuilder) are much less accessible. OmniBrowser looks much more comprehensive, but I don't feel qualified to comment on its usability as abstraction layer. I have taken a look at creating a google issue browser with Glamour (before ssl support) and think the committer workflow should be able to be improved with a few specialized Glamour browsers. But my opinion does not matter so much. That decision should be taken by the people maintaining the core of Pharo. Does Glamour provide enough functionality to build a whole tool chain? The focus of Glamour is on navigation in a single window, the language for updating and editing is limited. Drag-and-drop support is missing. Should the programming style of Glamour be the style to build basic tools in Pharo? Would it be better to use something more similar to the Seaside canvas style? The behavior change based on the number of block parameters is very powerful but imho also confusing. On the other hand I'm pretty sure HelpBrowser initWindow is worse than the equivalent Glamour code would be. At the moment the modularization of Pharo is not yet good enough. It is not easy enough to (de)compose images, so the maintainers need to have in the core image code to create user interfaces (web-based :) or direct). When we can create very small images and work with them using remote tools, this need will disappear. Committing to a tool chain build on top of Glamour would mean either back porting Glamour to earlier versions of Squeak/Pharo, so the new tools can replace the old ones everywhere, or breaking old tools and having to maintain them all ourselves. That is, if current maintainers agree with that. Happy new year, Stephan
[Pharo-project] FOSDEM devroom
Yesterday we had a nice day filled with great presentations. Getting to Brussels the day before proved to be a challenge, as the Dutch railways showed to have lots of trouble with 3 cm of snow and a cold night. Andy showed us a good place to eat and talk near the Central Station. In the end all presenters managed to be on time and the whole day ran smoothly. As the devroom was the second day of FOSDEM, we thought it wise not to start too early. That was a good idea, as the ULB was still very quiet when Norbert showed us how to create REST/json/xml based services. Markus followed with the Pharo Vision. Gradually more people came to the devroom until the jQueryMobile presentation was so filled that we had to refuse people entering the room. The Amber presentation also attracted a lot of people new to smalltalk. The ability to create a fast feedback cycle apparently is a major issue for javascript developers. The progress made since ESUG2011 is impressive. The next subjects (working with many cores, making smalltalk fast, spoon) still attracted over 40 participants. The introduction to smalltalk attracted quite a lot of young developers. Some remarks by participants: - a consistent set of keybindings, allowing switching between windows is essential (a developer who has trouble using a mouse for longer periods); - current developers are no longer used to free floating windows, it doesn't matter if it is better, to attract new people you need to remove barriers to entry (a freepascal maintainer); - I would have expected to have started with the basics (we focused on the things we experienced as difficult and different, using the different inspectors and browsers to navigate a large codebase, debugger driven development) And some reminder for ourselves - Tests for the domain model are not enough to ensure that the whole application works correctly; - Throw away old builds; - Check if there are enough power strips. I very much liked talking to people otherwise only known from the mailing lists and the cross-pollination between the different dialects. I would have liked to have more time for discussions. A lunch break might be a good idea. And finally a remark for next years devroom manager: don't expect to see much from FOSDEM :) Stephan Eggermont
Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers
Janko wrote: Tabbed browsing on VisualWorks is what I found a right compromise between many browsers and tabs. See attached screenshot of my current development desktop. There is in my opinion still a lot of potential for improvement in this UI: - the UI is extremely cluttered; - the browsers take way too much space for the menu bar, the tool bar and the status bar, leaving only 6 lines of scrolling; - an immediate improvement could be made by replacing the menu bar, tool bar and the status bar by something like a stay-on-top context-sensitive inspector; - the color/font scheme doesn't allow one to see where current focus is and makes it difficult to see which tab is selected; - why are class names bold? - package/bundle column isn't wide enough: AIDA is a nice short name, but the different Cloudfork-ActiveItem subpackages would be unreadable; - tabs are not used correctly: compare on the first line WebEventHandler class with Package on the next: the grey line should be removed; - the 3D effect could be removed to get a much cleaner look and more space for content; - a scrollbar could be used that allows one to see text below it; - a find box could use a shadow label inside the box (or a looking glass); - the toolbar items are context sensitive but don't grey out when not applicable; - the toolbar icons are not distinctive enough Stephan Eggermont
Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers
Fernando wrote: I would like to hear your opinion on the benefits of such interfaces, besides the fact that mainstream IDE's adopted it, it's not that i don't like Eclipse , is more that i'm aware that several difficulties have been found with these type of interfaces. On a large screen, I find the current Pharo layout already very much superior to Eclipse, Visual Studio and Delphi. Tabs provide not enough context, a card-based layout can do better. Please don't refer to inaccessible material (a.o. acm, ieee, springer, elsevier) unnecessarily. [1] http://dl.acm.org/citation.cfm?id=1062492 http://www.cs.cmu.edu/~ajko/papers/Ko2005MaintenanceTasks.pdf [2] http://dl.acm.org/citation.cfm?id=1806866 http://www.cs.ucf.edu/~jjl/pubs/ICSE0289.pdf [3]http://dl.acm.org/citation.cfm?id=1810295.1810331coll=DLdl=GUIDECFID=85166644CFTOKEN=21108183 http://research.microsoft.com/pubs/121031/CodeCanvas-ICSE10-NIER.pdf [4]http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6070389 http://www.dcc.uchile.cl/~rrobbes/p/VLHCC2011-gaucho.pdf Stephan
Re: [Pharo-project] Why do we use Pharo? a.k.a. rethinking Pharo marketing
We use Pharo commercially because it offers us a number of critical competitive advantages: - the superior environment makes development fun; - the short development feedback loop allows us to learn and improve; - open source cross-platform allow us to make deployment decisions purely on technical reasons; - the talent in the community gives us the guarantee that we can buy our way to a solution if needed; the focus on both research and commerce makes sure that there are good people that continue improving Pharo and that they can stay in the Pharo community after graduating; - the availability of frameworks such as MOOSE and Seaside and the good compatibility with Gemstone allows us to provide better solutions faster. Stephan Eggermont Sensus, systems that make sense
[Pharo-project] GSoC proposal: Naked Objects using Magritte
After a discussion with Esteban, Nick challenged me to submit a proposal. An alternative would be to start from Glamour instead of from Magritte 3. Proposal: Extend Magritte 3 to create Naked Objects style interfaces Level: Intermediate Possible mentor: Stephan Eggermont Possible second mentor: Esteban Lorenzano Description What if you never had to write a user interface again? What if you could simply expose your business objects directly to the end user? How would this affect your productivity? The way you work? The flexibility of your applications? Is this even possible? Sometimes, yes. This describes a style of application development, Naked Objects, where you write just the business objects, and a framework lets your users interact directly with these objects. (Dave Thomas) Technical Details Using Magritte we can already build (web/glamour)components representing attributes of domain objects. What should we add to enable a NO UI? - (better descriptions of) relationships between domain objects; - descriptions of actions, with and without parameters; - build a canvas where multiple domain objects can be shown; - make the domain objects identifiable with an icon and title; - add drag-and drop to initiate actions and manage relationships; - add buttons/drop down menus for actions; (and a few other things, of which I'll think when these are finished :) Benefits to the student Learn to use and extend a high quality framework. Learn and practice interaction design. Learn about hexagonal architecture. Benefits to the community The Naked Objects UI enables a very short feedback loop when prototyping a domain model. It provides a showcase for the superiority of smalltalk as a rapid development environment. It allows scaling down the engineering effort needed to create custom solutions. It fits very well with exploratory modeling. In a mixed UI style it allows focusing effort on only the critical parts of the UI.
Re: [Pharo-project] Pharo Consortium Important Documents and Request for Feedback
A good document, Stef. The current focus of the documents is on developers. It might make sense to add something for the (corporate) users of Pharo-based software. Stephan
Re: [Pharo-project] International Workshop on Smalltalk Technologies 2011
Hello Alain, Are there links to the articles, instead of a paywall? Stephan
Re: [Pharo-project] GSoC proposal: Naked Objects using Magritte
Stephan, I can help as second Mentor if you still need one. ...Stan I haven't been able to reach Esteban yet. He is supposed to be moving this week. Thanks for the offer. Stephan
Re: [Pharo-project] [gsoc-mentors] One more project proposal for GSoC
On 2 apr 2012, at 19:41, Dennis Schetinin wrote: The original idea is to build a two-tier Human-Machine Interface (HMI) system (which can be used in a wide range of projects) with Pharo image as back-end (where a model lives) and Amber-based client as a front-end. But this thing seems to be a little bit too large for GSoC, isn't it? As long as he's able to define value-delivering small, concrete steps it is ok to have big goals. Stephan
Re: [Pharo-project] How can I do literate programming?
You should probably use a MOOSE image if you want to do the modern equivalent of literate programming. Instead of comments, drive your code from (behavioural) tests, create glamour mondrian browsers to visualize the design and quality attributes of the code and use magritte style descriptions to declaratively describe your domain. Then generate LaTeX pictures from this for the paper trail. Stephan Eggermont
Re: [Pharo-project] Artefact - a PDF framework
Hi Olivier, I've taken a look at the state of Artefact. Don't you think it would be much less work to port Christian Haider's work to Pharo? The namespace extensions to ring should be helpful to make two-way changes from both the VW and Pharo side. Stephan Eggermont
Re: [Pharo-project] Artefact - a PDF framework
Why do we have so many ways to create pdfs, and why do most libraries/frameworks only provide a partial solution? At first it seems not to difficult to build something for what I need, so it makes sense to build it myself. But the pdf spec is large, and I don't use most of it. Building it myself makes more sense than trying to understand a current implementation. That is more complex than needed to solve the current problem, and building my own is a good way to understand the spec. Completing an implementation is hard to justify on project costs (as is mostly done for open source). More people seem to have followed the same road, so we end up with lots of partial solutions. Next time I need to create pdfs, I have different needs. Something with fonts, that seems like a lot of work. So I connect to a c library that already implements it. Only that has no way to create a document in-memory, just on disk… Artefact at the moment has very simple text layout and table algorithms. They are suitable for simple documents. High quality layout is complex as it needs to handle a.o. line breaking, justification, ligatures, kerning, hyphenation, text direction, text container shape, paragraph and page layout. PDF4Smalltalk is large because it is able to read and write pdfs, so it needs to have at least basic support for all pdf elements, and it contains lots of constants and mappings (glyph list, font metrics). Cairo (and Pango) by itself does not support reading pdfs. Stephan
Re: [Pharo-project] dependency injection
Philippe wrote: On 05/05/2012 10:04 AM, Milan Mimica wrote: What are you feelings about dependency injection? Oh oh, you brought up the topic. We have about six different ways in Seaside how we look up implementation classes. Anything from writing them to a class variable to iterating over the subclasses and class extensions. It would be really nice if we could replace them with one approach. So that would be: afraid/angry, confused, despairing/hopeful? :)
[Pharo-project] Place to sleep Lille?
Hi, Hmm. I'm a bit late to make a hotel reservation. Most hotels seem to be booked out. Anyone know an alternative? I'm arriving by train on wednesday. Couch would do. Stephan Eggermont
Re: [Pharo-project] Place to sleep Lille?
Damien wrote: Try this one: Hotel ibis Lille Opéra 21 Rue Lepelletier, 59000 Lille, France +33 3 20 06 21 95 Thank you. I already did. No space. Stephan
Re: [Pharo-project] Place to sleep Lille
Hi Stef, Thanks. The Formule 1 still had a room (others didn't). What's the place to meet on wednesday evening for a beer talk? I'll arrive 21.00 or so. Stephan
[Pharo-project] Before-conference beer?
I'm arriving wednesday evening about 21.00 hr. Anyone up for beer talk? Stephan
Re: [Pharo-project] Before-conference beer
I've checked my train ticket. I'll arrive at train station Lille-Europe at 19.52. I assume it has an info-point or so? Stephan
Re: [Pharo-project] Before-conference beer
Marcus wrote: On May 22, 2012, at 12:59 PM, Camillo Bruni wrote: otherwise a good meeting point is in front of the old trainstation Lille Flandres (about 200m / 1 metro stop from Lille Europe) Yes, in front of the main entrance of Lille Flanders is a good meeting spot. Ok. 20.00 I'll be at the front of the main entrance of Lille Flanders. Stephan
[Pharo-project] Visualizing Legacy at SPA conference
Last week Willem and I presented a workshop Visualizing Legacy, using MOOSE, at SPA2012 in London. In a 150 minutes workshop we showed how to use glamour and mondrian to visualize the github repository data from 4 ruby projects and the code used for these analysis and the workshop itself. The exercises work toward the creation of a glamour browser with a mondrian pane showing custom visualizations not achievable by more static tools like Sonar. The answering of specific questions that arise during the analysis of the data show the strengths of the MOOSE toolchain. We started by showing some of the work Diego and I have done for the conversion of the data of a cobol ERP system to a modern ERP system. By creating (at least) one browser/visualization a day, we were able to make the subject matter expert, a very busy senior executive of the company, steer the conversion process to her satisfaction. By treating her as the bottleneck, and making it as easy as possible for her to see where we were, and what we still had to do/understand, she could effectively prioritize and decide. Then we asked the participants what they expected/wanted from visualizing their legacy code. The answers were a mix of things that tools like Sonar can easily provide, with very specific questions that need a programmable tool like MOOSE. As we expected, it took most of the about 14 participants quite a lot of effort and time to get to grips with the smalltalk environment to work in. So much so, that some asked for a separate smalltalk workshop to do before this one, or a larger timeslot for this workshop. The few participants experienced with Smalltalk had been using VW/VA and also had some problems finding their way around. In the end, the participants who managed to just follow the exercises achieved the goals without too much interventions needed. Inspired by ProfStef, we build a custom glamour browser for the workshop. The code can be found in the SpaTutorial project on ss3. (The ConfigurationOf… is no Metacello) http://ss3.gemstone.com/ss/SpaTutorial It is split in a generic part, allowing you to create tutorials, and a specific part for this workshop. We might want to extend it so the exercises can be done entirely in the custom browser. That might help the smalltalk newbies. Now the participants needed two class browsers in addition to the tutorial, one to edit the exercise code, and one to look at the domain model. We believe the learning curve can be flattened by extending the SpaTutorial browser so it can save code, and extracting some methods so the tutorial browser only shows the bits participants have to work on right now, gradually expanding the scope as it progresses. It uses the data collected for the SPA2011 great egg-race. http://chatley.com/posts/06-20-2011/spa-great-egg-race/ Git commit data was collected by Michael Feathers from four ruby projects, a.o. active_merchant and diaspora. After my holidays I'll put the data in a zip in https://github.com/StephanEggermont/repodepot-ruby For the 150 minute timeslot we focused on glamour and mondrian, although we also prepared an eyesee exercise. Next time we might switch the exercises around - mondrian looks more glamourous than glamour ;). A longer version may also be in the works if we can run it somewhere. It was only after the mondrian exercise that participants could start playing with the data on their own. Participants indicated they associatied mondrian more with visualization than glamour. Stephan Eggermont Willem van den Ende
Re: [Pharo-project] Memory usage
Dave wrote: Please try the 64bitImage*64bitVM image from John's site here: ftp://ftp.smalltalkconsulting.com/experimental/64bit/ Loads and runs on my 10.7.3 MBA. If you can run that VM on your Mac, it should do exactly what you need. Try running that VM with one of your images. If it runs and gives you some sort of error message about not understanding the image format, that's good! That means all you need to do is trace your image to 64-bit object format, which should be fairly easy to do. I loaded SystemTracing-dtl.23.mcz into a Pharo 1.4 one-click. SystemTracer2 writeImage: 'clone.image' results in a 88 byte clone image and hanging image, non-interuptable, caused by the popping up of a deprecation warning. Switching off the deprecation blocking leads to a debugger popup when trying to add the specialObjectArray. #'==' doesn't seem to work as a equalsBlock in Pharo. replaced by equalBlock: [:one :two | one == two]; The method SmalltalkImage extraVMMemory has been deprecated use Smalltalk vm extraVMMemory Then the tracing finishes. Trying to start the image results in 8/1/12 11:52:00.915 PM Squeak: openFile state 1 with file /Users/stephan/Documents/Sensus/sq64-dtl-32bitRGB/clone.image 8/1/12 11:52:01.098 PM Squeak: NSAlert is being used from a background thread, which is not safe. This is probably going to crash sometimes. Break on _NSAlertWarnUnsafeBackgroundThreadUsage to debug. This will be logged only once. This may break in the future. 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: Recursive not understood error encountered 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4423897840 SystemTracer2writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4403075464 BlockClosureensure: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4407168048 SystemTracer2writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4410156840 writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4411453984 UndefinedObject? 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4412035392 Compilerevaluate:in:to:notifying:ifFail:logged: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4413449752 SmalltalkEditorevaluateSelectionAndDo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414213432 BlockClosureon:do: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414486112 SmalltalkEditorevaluateSelectionAndDo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414725120 SmalltalkEditorevaluateSelection 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414946416 SmalltalkEditordoIt 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4415487880 SmalltalkEditordoIt: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4415621456 TextEditorperformCmdActionsWith:shifted:return: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416886344 TextEditordispatchCommandOn:return: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416913992 TextEditordispatchOn: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416972032 TextEditorkeystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416996176 TextEditorhandleKeystrokeAction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417061696 TextEditorhandleEditionAction:fromKeyboardEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417061880 TextEditorkeystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417084280 TextMorphbasicKeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417143280 TextMorphhandleInteraction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417163504 TextMorphForEditViewhandleInteraction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417163720 TextMorphbasicKeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417214616 TextMorphkeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417234096 codeCompletionAround:textMorph:keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417279920 ToolRegistrycodeCompletionAround:textMorph:keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417280104 TextMorphkeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417299408 TextMorphForEditViewkeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417350856 TextMorphhandleKeystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417369760 KeyboardEventsentTo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417417472 MorphhandleEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417435496 MorphhandleFocusEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417476608 HandMorphsendFocusEvent:to:clear: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417494152 PasteUpMorphbecomeActiveDuring: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417537816
Re: [Pharo-project] Memory usage
Guile wrote: Yeap, but it I'd not call it an update :). It is more a complete refactor to make it more understandable to newbies like me. Anyway, I didn't migrate the code to write 64bit image, and I'm not planning to do it in the short term... If you want to take a look, the project is in ss3/ImageWriter The differences between SystemTracer2 and SystemTracer64 are rather limited. Should I expect that to be similar for ImageWriter? Stephan
Re: [Pharo-project] New Text Completion suggestions
Doru wrote I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides. +1 Stephan
Re: [Pharo-project] New Text Completion suggestions
Camillo wrote: So you're saying modifiable keyboard shortcuts are a bad design? Yes. That is to say, using them outside of developing a good set of key bindings (possibly for each language/keyboard). We need them to get to this consistent set. Options could be on the level of vi/wordstar/emacs style. Stephan
Re: [Pharo-project] Sending email with Pharo
Hi Hilaire, There was a post from Scott Sproule on using Amazon SES with zinc and stunnel. Sven, you remember? From the response it was not clear to me if he managed to get everything working, and the need for stunnel might not be there with the current SSL support. SES is about 10% of the cost of postmaster. Attaching to mail is a well-known process. There are no problems there. Stephan
Re: [Pharo-project] nautilus speedup?
Camillo wrote: I did a quick nautilus improvement: https://code.google.com/p/pharo/issues/detail?id=6667 CAVEAT: One thing I did was not showing all methods when opening the browser on a class. For me this makes perfectly sense since I use the CMD-F + CMD-M shortcut for searching for a method. Or go over all the protocol using the arrow-keys on the selected protocol list. what do you think? It sounds like a perfect idea to get some traction for getting rid of method categories. Why would anyone want not to look at all methods in a class by default? In well refactored code, the number of methods is so limited that no scrolling should be needed. Not all code is like that, of course. Reading code is the most important activity of developing, and it is essential to limit the interaction needed to browse through code. Much better would be to show in the code pane which instance variables have accessors (r/w) and show all without accessors by default. However I can see that a classical user might be disturbed. This cut's down the opening lag of a new browser from ~400ms to ~200ms on my machine, to me thats quite worth it :). If the problem is performance, focus on performance. Why can not showing 30 items in a list make a difference of 200 ms? Stephan
[Pharo-project] Default max heap size on OS-X
Hi I noticed the default SqueakMaxHeapSize on CI for Mac is 536870912 bytes. Is there a specific reason for the default to be so low? I know there used to be problems with the windows vm. Stephan
Re: [Pharo-project] Native UI bundle for Mac
Hi Pavel iMac 27 11.1, 10.6.8 works fine. Resizing the pharo window gives a screen with garbage and then mostly removes the pharo window. XUL stays up, but no longer switches views. Stephan
Re: [Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM
http://stackoverflow.com/questions/1496788/building-for-10-5-in-xcode-3-2-on-snow-leopard-error
Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree
Hannes wrote: Some people however do not mind to do mappings from one data format to another. That is right, and I prefer to keep my meditation separate from my programming. Stephan Eggermont
[Pharo-project] Status of SmallPOS
I noticed the SmallPOS on ss3 is under MIT license. AFAIK, it was GPLv3. When did this relicensing happen? Stephan
Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)
Igor wrote: Anyways, UI stuff is tend to be complex no matter how nicely you wrap it.. because it is UI. I'd have to disagree there. Building UIs with Glamour is easy. I'd say Spec is simply at too low an abstraction level for most UI work. We might need a different abstraction for different kind of applications (non-browsers, something like hotdraw comes to mind), but Glamour provides a very good base for most of the tools in the Pharo image. Stephan
Re: [Pharo-project] Do you know any code that can be better understood with its test?
Stef wrote: bitShift: look at the tests ((1 bitShift: 100) bitShift: -100) = 1 For even better understanding, add ((1 bitShift: -100) bitShift: 100) = 0 Stephan
[Pharo-project] How to export multiple Pharo packages to VW
The VW5PackageExporter allows the exporting of a package to the VW xml based fileout format. I've adapted the code to be less Seaside-specific, and am now able to export one package (Parasol-Core). If I try to export another package (Parasol-Tests), which depends on the earlier one, it fails to load. It can't resolve the dependency to a superclass defined in Parasol-Core. I've seen that Roassal puts all Pharo packages into one VW package. That would work, but is not very nice. A package in VW doesn't seem to register its dependencies in a fileout. Would creating a parcel help, or should I try something on basis of RPackage? Stephan
[Pharo-project] Squeaksource memory
I was added as developer to PackageInfo 2 weeks ago, but am no longer able to commit... Stephan
Re: [Pharo-project] Getting Started with Athens
Camillo wrote:
curl http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | bash
./vm.sh Pharo.image config http://squeaksource.com/Athens
ConfigurationOfAthens --install=1.4
It downloads and installs fine. But how do I need to start it to make it work
(10.7.5)?
The directory structure looks a bit of a mess. The vm directory contains some
34 files,
and dragging the image on NBCog doesn't work. Starting with vm/NBCog Pharo.image
starts the image, but trying to run an example:
Stephan
Error: failed to get a symbol address: cairo_image_surface_create
NativeBoostMac32(Object)error:
NativeBoostMac32(NativeBoostLinux32)getGlobalSymbolPointer:
NativeBoostMac32(NativeBoostLinux32)loadSymbol:fromModule:
NativeBoost classloadSymbol:fromModule:
Metaclass(Object)nbGetSymbolAddress:module:
NBFFICalloutgenerateCall:module: in Block: [:gen | ...
BlockClosurevalueWithPossibleArgs:
NBFFICalloutgenerateInstructions: in Block: [aFunctionBodyBlock
valueWithPossibleArgs: {self. ...etc...
BlockClosureensure:
AJx86AssemblerdecorateWith:during:
NBFFICalloutgenerateInstructions: in Block: [:call | ...
AJx86AssemblerperformingCall:in:
NBFFICalloutforeignCall:
NBFFICalloutgenerateInstructions:
NBFFICalloutgenerate:
NBFFICalloutgenerateCall:module:
AthensCairoSurface class(Object)nbCall: in Block: [:gen | gen sender:
sender;...
NBFFICallout class(NBNativeCodeGen class)generateCode:andRetry: in Block:
[bytes := aBlock...
BlockClosureon:do:
NBRecursionDetect classin:during:
NBFFICallout class(NBNativeCodeGen class)generateCode:andRetry:
NBFFICallout class(NBNativeCodeGen class)handleFailureIn:nativeCode:
AthensCairoSurface class(Object)nbCall:
AthensCairoSurface classprimImage:width:height:
AthensCairoSurface classextent:format:
AthensCairoSurface classextent:
AthensDemoMorphinitialize
AthensDemoMorph class(Behavior)new
AthensDemoMorph classDoIt
Compilerevaluate:in:to:notifying:ifFail:logged:
Re: [Pharo-project] Getting Started with Athens
Camillo wrote: indeed just reproduced it. I guess I'll have to add a special OSX case. mv vm vm.app that should fix it when running from the UI. That fixes the start on drop-ability all right, but doesn't help with finding Cairo Stephan
Re: [Pharo-project] File sharing on the network
Hilaire wrote: Is there anyway to implement fileshareing with Dropbox or GoogleDrive on a Pharo client application? I can see some use cases for a globally persistent peer-to-peer based system. Sort of a distributed github. Centralized systems tend to bring all kinds of nasty spam and privacy problems with them. Stephan
