May 2020 - Pharo-dev - lists.pharo.org

would it make sense to have ZnCharacterReadStream and other readstream reply to readstream
by StÃ©phane Ducasse May 18, 2020

May 18, 2020

Hi sven I like the pattern on: aStringOrStream | stream | stream := aStringOrStream readStream but I cannot apply with Zn because ZnCharacterReadStream and friends do not answer readstream What is your point of view on it. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

2 2

pharo-contributions/pharo-unicode
by Sven Van Caekenberghe May 17, 2020

May 17, 2020

Hi, I am not 100% sure how things are organised, but I would like access to pharo-contributions/pharo-unicode, so that I can commit directly. I see that Alistair did the initial commits (copying from history), but I can't see how he could have done that. I access granted at the pharo-contributions level, or below ? Thx, Sven

1 0

Red Alarm!
by Janko Korelc May 17, 2020

May 17, 2020

Red Alarm! 2 days ago had found databaseCriticsBrowser.zip and installed several packages from the catalog. NeuralNetworks installed successfully for the first time. Several image saves later, was dissatisfied with something, and as noticed option to revert changes, tried it. Look, everything got uninstalled! WTF? Thought, then at least let's install NN again. Only to discover I can not. Today, I believe it got deleted for a strange reason. Try to recover and those dangerous variants shall be removed from the public. For the curious look in group Compiler at my comment in topic: What should we do with programmers who introduce errors in code. -- gee, gravitino, graviton exchange

1 0

Squeak and Pharo why the fork
by Shaping May 17, 2020

May 17, 2020

Hi Jimmie. On 5/15/20 5:26 AM, Shaping wrote: I donât understand the split. It looks silly. Maybe someone can explain the split in terms of technical/architectural advantages, if any exist. I began using Squeak about 20 years ago. And then Pharo when it started. I will explain as best as I can. The differences do have bearing on architecture and technical things but at the beginning the basis of it all is philosophy. Differences in what you want Squeak/Pharo to be, where you want it go. Squeak is from Apple Smalltalk. Smalltalk is not simply a language, but began as an OS, an environment and a language. It ran directly on the hardware. Then Smalltalk was ported to operating systems. But still took with it a very OS like environment and world view. It was the world. This was very much Squeak. Squeak was the world. It was an amazing and interesting environment. It could play mp3s, had MIDI capabilities. It was a very interesting multimedia environment. Bright, colorful, creative. But it was also a very productive programming environment to build whatever you wanted to build. All of the people involved in Squeak, loved the productivity of the Smalltalk language and the live environment. You had debates about "Pink plane" vs "Blue plane". What was the direction of the community and the artifact Squeak. There were two large communities with differing opinions on direction. Alan Kay The Computer Revolution Hasn't Happened Yet OOPSLA 97 Keynote (VPRI 0719) https://www.youtube.com/watch?v=aYT2se94eU0 """ https://pab-data.blogspot.com/2007/03/what-colour-do-you-like-your-objects.… In Alan Kay's keynote speech at OOPSLA in 1997 he talks about a blue plane and a pink plane. The pink plane represents ideas which are an incremental improvement of existing ideas. The blue plane which runs orthogonal to the pink represents revolutionary ideas that break the old way of doing things, setting you off in a new direction. """ Many people had projects and ideas which were very able to be done in Squeak, but did not want the entire OS-like image. ... Maybe I want a web server. I don't need to play multimedia files. Have a GUI. etc. Insert your own application here. People wanted to build businesses around what they could do with Squeak. The Pink plane community wanted to begin to clean up Squeak. Break it up into parts which could be reloaded. It wanted a much more modular environment which allowed you to build the image you want for the purpose you intend. The Blue plane community didn't see any problems with the way it was. They liked it and still do. It fit what they wanted to do with Squeak/Smalltalk. Frequently more research oriented and less business oriented. Applied basic research is most of what I do. I still want a clean, modular environment. I donât see how that interferes with creative verve. It should help if only by limiting confusion and clarifying configurational choices. Then in the midst of all this you have overlap in individuals who understand both. You also had personality differences and disagreements which developed over years. Eventually the Pink plane community forked and created Pharo. The foundational community of Squeak (Blue plane) did not want to make the changes the Pink plane community wanted or required. What are the specific changes that Squeak folks donât want to make? Squeak/Pharo is a configurable environment. We can still have a quasi-OS world if we want that. What specific aspects of the analytic and creative experience break or degrade for Squeak users with these specific changes, and also cannot be preserved by loading the right Smalltalk packages? Pharo is now 12 years or so into its journey. It is not easy losing weight and still keep working. But that is the goal of Pharo. Keep reducing until the entire system can be built up from a base image. And when it gets there. We don't have a problem with from that foundation, being able to build it back up into a Squeak-like image. I have numerous projects which I am doing in Pharo. One is a trading application. I personally want as little in my image as possible which does not have to do with my trading application. It desires to be as fast as possible, run without failure, and as memory and cpu efficient as I can make it to be in Pharo. I could make and run this application in Squeak. But it would include much that I don't need and don't want. And that is the case in Pharo currently as well. This points to needing more modularity, not less. We want to unload all that we donât want, in small or big pieces, easily and confidently, without breaking anything. It sounds easy, but itâs not. I think this should be one of the Consortiumâs main goals. But Pharo has its philosophy and its direction that it is moving towards. At some point in time my trading application will what I want it to be with very little unused code in the image. That might not be until Pharo 10+. I don't know. But there is a vision within Pharo for people to build such applications. Image minimization is a useful feature. A Squeak user would want this too, at least when deploying. I have not used Squeak in years. And nothing I write here is meant to speak badly about Squeak. I like the Squeak community. They are full of great people. And I do not know how accurate what I write is to the current Squeak. My apologies for any inaccuracies or errors. Pharo in general is much more pro-business. It is an explicit goal of Pharo. https://pharo.org/about https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf Both websites give you a feel for who the community is and the orientation of their goals. As much as re-unification would be nice. Logical and utilitarian. I don't know that it will happen. At a minimum, not until the Squeak community could build Squeak from a Pharo kernel image. Then it would be possible. But I don't think likely. What are the specific problems? Anyone? This is just my generalizations in an effort to answer your question. There are people who are in both communities. Both communities in general attempt to cooperate when we can. Both are communities with friendly, amazing people. And both communities have people who have been doing this for a very long time, and that is a very good thing. Both are completely open source projects which will allow you to do whatever you want within your abilities and resources. Basically it is simply this. Different visions for the direction of the project and the pursuit of those directions for an extended period of time. This email is an simplification of a lot discussions and debates over a period of years which finally lead to a fork of Squeak. Hope this helps. Shaping

5 6

Re: [Pharo-dev] [Vm-dev] Squeak and Pharo speed differences
by Shaping May 17, 2020

May 17, 2020

Hi Shaping, I can't comment on parallelizing the VM. Thatâs mostly what the thread is for, ultimately. The refcaps are needed by the concurrent collector. Some interesting memory-management options are surfacing soon with Verona. That scheme is supposed to eliminate the cost of tracing refs to mutable objects in many small heaps. This is the main cost of having all the small heaps with Orca protocol. Verona should fix this. I need to look into it further before discussing the details. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model. Sorry for the delay. Iâve not read the e-mail yet. Iâll be a bit longer. Thanks for the patience. Shaping On 5/16/20 11:29 PM, Shaping wrote: Hi Shaping, Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) On 5/16/20 8:47 AM, Shaping wrote: Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. Who oversees stuff like this? Specifically, why donât we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimatelyâa nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time. Why wasnât this done when Tonel was first created? The Pharo dev probably didnât see it as good use of dev time. I kindly suggest that this attitude change for all contributors to both Smalltalks. How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things? I couldn't get distracted from my core work. Sure, I feel the same. I imaging that most of us do. NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, In my Pharo 9 I have a bit these bits: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load In Squeak I can now ensureRecentMetacello, which I was not able to before. Installer ensureRecentMetacello. Metacello new baseline: 'MagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'; load However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring ...FAILED->BaselineOfMagicMouse I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus: spec name: 'BaselineOfMagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'. At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak. Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo. Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; project: 'Cryptography'; install: 'ProCryptoTests-1-1-1'; project: 'Cryptography'; install: 'CapabilitiesLocal'; project: 'Oceanside'; install: 'ston-config-map'; project: 'Cryptography'; install: 'SSLLoader; project: 'Cryptography'; install: 'Raven'. Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo... If there is genuine respect for the value of Squeak and Pharo on both sides Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that.. K, r -- Kindly, Robert

1 0

Re: [Pharo-dev] Squeak and Pharo: why the fork
by Shaping May 17, 2020

May 17, 2020

On Sat, 16 May 2020 at 16:57, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: You also had personality differences and disagreements which developed over years. Eventually the Pink plane community forked and created Pharo. The foundational community of Squeak (Blue plane) did not want to make the changes the Pink plane community wanted or required. What are the specific changes that Squeak folks donât want to make? Squeak/Pharo is a configurable environment. We can still have a quasi-OS world if we want that. What specific aspects of the analytic and creative experience break or degrade for Squeak users with these specific changes, and also cannot be preserved by loading the right Smalltalk packages? At a minimum, not until the Squeak community could build Squeak from a Pharo kernel image. Then it would be possible. But I don't think likely. What are the specific problems? Anyone? I'm mainly focused on Pharo but I respect the Squeak heritage and monitor their mail list, chipping in when I can - so I have felt comfortable sharing the general philosophical differences between Squeak and Pharo as I understand them. But as to specifics, you'd probably need someone from Squeak to pair-review the Pharo changelogs [1] with you - and that might not even capture everything. [1] https://github.com/pharo-project/pharo-changelogs But lets also consider something at least as important as all the other points... "resourcing". Assuming all technical and political issues were dealt with, who will do this reintegration work? The work should be distributed amongst those who know the frameworks best, like them and need to use them, and who want one image and the ease it bringsâwhich should be a bunch of people. Or, Iâd have to work with those folks to get up to speed on those frameworks to learn whatâs different, whatâs broken, what can change, what canât change, etc. Doing it all myself even with plenty of consulting seems less efficient. Selfish drivers are important. Community/collective drivers are also important. Balance. Donât leave out the first, or nothing will happen. Assuming You were at a point where you were familiar with both platforms to be capable of doing the work, would You be willing to put aside your other interests to do at least 50% of that work? Probably not for the next year, because of whatâs currently in my queue. Because otherwise discussion around it with the idea that others do it is pointless. :) I see several devs doing the work. One dev probably canât do it. At least one dev should be watching the big picture and presenting results/problems/decision-points. The big picture may not be as big as Iâm thinking. It could be bigger too. I need details. I have one firm detail now: 1. Squeak folks need Tonel. Ergo, port the latest Tonel to the latest Squeak. And two fuzzy details: 1. We need testable criteria to determine how indispensable/always-in-the-image/nonmodular a framework shall be. Itâs an interesting topic. I donât know how itâs currently handled. Development seems organic and wild-west in both camps: if you can get it done on your own time and it provides utility, it can probably get into the main trunk somehow. Is that how it works? 2. Metacello sucks a little for brevity, and Monticello seems to offer some nicer features. And so what do we do here? Fix the Monticello/Metacello frameworks on both sides, or move all to Git? Whatâs wrong with Metacello? Is it too verbose? Can an SME/heavy user defend it and compare it to Monitcello? I want to know what is most valuable about Squeak, and I mean specific features and tools. We can turn either Pharo or Squeak into a world-like Quasi-OS. Thatâs not an argument for greater technical value. It just a mode of use. I can tell you want I like about Squeak (please Squeak folks, add to this), but Iâm almost Squeak-green again after 16 years absence: 1. Flat quick GUIs for development. I just like snap. What can I say. It helps me focus. Iâve sensitive to what I consider to be temporal defects (annoying little pauses). That doesnât mean I like Morphic. I like what I can see and touch, and I like the speed. 2. Debugger is normal (quick). 3. The VM params and stats. I want to work on the VM. I want to do that with nice-looking, quick tools. I thought Pharo would be the best for that. But Squeak seems to be the main tool for VM dev. Note, last year I personally did have the inspiration and intention of investigating the differences between Squeak and the Pharo Bootstrap to understand the possibility of Squeak bootstrapping off the Pharo Bootstrap, so there might one day they might have a common non-gui system - but other interests ended up having a stronger hold on me. Realistically its not something I'll get to any time soon. I too find the common bootstrapping interesting. My personal priority is efficient, thorough parallelization of the VM. I need huge compute-scale, and it has to happen in a dynamic language, the best one. Thatâs going to keep me busy for a while, and I canât even start that for some time (months). Shaping

1 0

Re: [Pharo-dev] [Vm-dev] Squeak and Pharo speed differences
by Shaping May 17, 2020

May 17, 2020

Hi Shaping, Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) On 5/16/20 8:47 AM, Shaping wrote: Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. Who oversees stuff like this? Specifically, why donât we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimatelyâa nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time. Why wasnât this done when Tonel was first created? The Pharo dev probably didnât see it as good use of dev time. I kindly suggest that this attitude change for all contributors to both Smalltalks. How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things? I couldn't get distracted from my core work. Sure, I feel the same. I imaging that most of us do. NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, In my Pharo 9 I have a bit these bits: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load So does this that mean Pharo strictly uses only Metacello and Git for version control now? from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. Yeah, thatâs not healthy for the community. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. Agreed. Thanks for plainly saying so. We need more of that. That is step number one to having features co-loadable, common load systems. Agreed. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :( It is very sad. Letâs fix it. Donât the Consortium have an interest in such things? Are the Consortium so Pharo-centric that they view Squeak as a useless blob of programming IP? I donât think so. If there is genuine respect for the value of Squeak and Pharo on both sides, allowing their continued divergence and the many attendant frustrations to mount is negligent and wasteful. Can we stop doing that? Iâm under the impression that Pharo folks want ultimately to use only Git, and that even the Metacello will be phased out. Is that correct? What is the version-control plan on Pharo, and can we implement the same planâwhatever that is--for Squeak too? Shaping

1 0

Re: [Pharo-dev] Squeak and Pharo speed differences
by Esteban Lorenzano May 16, 2020

May 16, 2020

Hi, Apples and oranges here. Yes, both are fruits (perceived speed), but thatâs the only point in common :) Apples and oranges because one thing is the overall performance of the environment and another completely different the perceived execution speed of the GUI. Still, some answers: > On 15 May 2020, at 06:47, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org>> wrote: > > Hi all. > > > Squeak 5.3: > Time millisecondsToRun: [ 100000 factorial ] 6250 > > Pharo 8: > Time millisecondsToRun: [ 100000 factorial ] 7736 > > Why the difference? I have no idea. But I have to say that IN MY MACHINE: Squeak 5.3, just downloade: Time millisecondsToRun: [ 100000 factorial ]. 6289 Pharo (9, regular VM): Time millisecondsToRun: [ 100000 factorial ]. "3585" This surprises me more than you, in fact because I was expecting similar times (VM is the same, after all). Basically, all this benchmarks are very unreliable and depend a lot on the machine you are running and ultimately, "weather conditions". > Squeak 5.3 release notes describe arithmetic improvements. Nice. I crunch very big numbers, and these improvements therefore have value. Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo? In general , since VM is the same, if changes are in VM they are already in Pharo. > Playing with Squeak 5.3, Iâve noticed that the GUI is snappier. Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer. (Still thatâs some work I prefer not to do.) Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2. I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs. The obvious question is: Will Squeak be improving GUI look/behavior and speed with Spec2? If not, can I load Spec2 into Squeak so that I can do new GUI work there? I donât know about Squeak, this is not the appropriate place to ask Squeak questions. But yes, Pharo is in a battle to improve its GUI (we are basically rewriting all tools with Spec2, but even that some times is not enough since Morphic has become bloated, so our fight for performant tools is constant. Pharo 9 will replace all glamour based tools (Playground, inspector and debugger), plus some more old tools, and all will improve there I think (GTTools are cool, but Glamour was slow). > Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word. I thought Iâd entered a wormhole. So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies. This matters to me. Iâm trying to port from VW to Pharo or Squeak (for a really long time now), and canât push myself past the text-selection delay problem. Can text-selection speed be improved to the level of VWâs? Can someone sketch the algo used and/or point me to the right class/methods. I donât knowâ¦ Iâm sure is possible, but someone has to do it :) What I can tell you is that text model/operation is a big concern for us... > The Squeak debugging experience step-to-step is much quicker. The latencies in Pharo after button- release are very long. I estimate 100 to 150 ms. Thatâs too long for me to work productively. I lose my mental thread with many of those delays, and have to restart the thought. Itâs a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs). Is speeding up the Pharo debugger with Spec2 a priority? I canât think of a better GUI-related priority for Pharo. Yes, it is a priority, but it is still a WIP. Part of this problems has nothing to do with GUIâ¦ thing is even if âdebuggerâ is same concept, our debugger and the old debugger (which squeak continued) have a complete different machinery behindâ¦ still, yes we are working. > > > Not speed-related: > > - How can I load additional fonts into Squeak? Pharo does this with the font dialogâs Update button. Youâll have to ask in squeak list, the sis not the appropriate place for that :) > - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge? Some of the Squeak panes have this; others donât. I want leading-edge action in all panes, and wish the feature were in Preferences/Settings. I do not understand what that is. Still, I guess the right answer would be: if it is not there, being (both) open source projects that are sustained by communities, and being you part of the community, I think it would be a nice contribution for everybody if you absolute need this and you invest some time on doing it. Iâm sure you will have all help you need to do it in both communities. Cheers! Esteban > > > > Shaping

6 5

May 16, 2020

Hi We have splitOn: '| a b | c d |' splitOn: â|' >> an OrderedCollection('' ' a b ' ' c d ' â') And I think that it would be nice to have '| a b | c d |' splitWithin: â|' >> an OrderedCollection(' a b ' ' c d ' ) Do you have idea? S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

2 1

Re: [Pharo-dev] [Vm-dev] Squeak and Pharo speed differences
by Stephan Eggermont May 16, 2020

May 16, 2020

Metacello works well across Gemstone, Squeak and Pharo Verstuurd vanaf mijn iPhone > Op 16 mei 2020 om 15:33 heeft Robert <robert.withers(a)pm.me> het volgende geschreven: > > ï»¿ > Hi Shaping, > >> On 5/16/20 8:47 AM, Shaping wrote: >> Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? >> >> I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? >> >> >> >> Make all features (GUIs/frameworks) loadable into a new, mostly empty image. >> > > Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. I couldn't get distracted from my core work. > > NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. That is step number one to having features co-loadable, common load systems. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :( > > K, r > > -- > Kindly, > Robert

1 0