October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Read-only images / how to deploy new image as fast as possible?

by Tim Mackinnon

Hi Herby - for #1, yes you can do that (I do this in PharoLambda) - there was a snippet from Sven on how to do it (you need to override 2 classes I seem to recall) , if you search in the archives you should find it. I'm not near a computer to give you the exact bit - but if you can't find it I'll pop a reply tomorrow. Tim Sent from my iPhone > On 28 Oct 2017, at 12:46, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hi, > > I came to the phase where I actually deploy the small backend written in Pharo, and I wonder about two things: > > 1. Is it possible to make .image / .changes read-only? Will Pharo just work (not writing the image, but that is not needed, all data are in sqlite file)? > > 2. How to "switch" images as fast as possible? I presume there is no way to tell vm to "stop doing this and reload different image" or something like that? I need to stop the runninng one and then start the new one? Or is it possible to "swap" the read-only image for new one and tell VM to reload (just wanting to minimize the off-time). > > Thanks, Herby >

Oct. 28, 2017

Read-only images / how to deploy new image as fast as possible?

by Herby VojÄÃk

Hi, I came to the phase where I actually deploy the small backend written in Pharo, and I wonder about two things: 1. Is it possible to make .image / .changes read-only? Will Pharo just work (not writing the image, but that is not needed, all data are in sqlite file)? 2. How to "switch" images as fast as possible? I presume there is no way to tell vm to "stop doing this and reload different image" or something like that? I need to stop the runninng one and then start the new one? Or is it possible to "swap" the read-only image for new one and tell VM to reload (just wanting to minimize the off-time). Thanks, Herby

Oct. 28, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Steffen MÃ¤rcker

I see. What is the task in detail? Are some of the set fixed or known in advance? What's the argument against a bitset-based solution? Cheers, Steffen Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >It was for test inclusion of UTF-8 characters so we do not want to >rely on external libraries. > >On Fri, Oct 27, 2017 at 1:54 PM, Steffen MÃ¤rcker <merkste(a)web.de> >wrote: >> Dear Andrew, >> >> I didn't find time to answer earlier. Some time ago, I was looking >for a >> (MT)BDD package in ST as well. I didn't found one. So the only two >options >> left are >> >> 1) implementing a new BDD lib in ST and >> 2) doing FFI to some existing lib, e.g. CUDD, Sylvan, Jinc >> >> I'd prefer 2) since the existing libraries are feature-rich and >highly >> optimized - which took quite some time. As a bonus, a solution could >> potentially switch between those backends. The biggest hurdle, in my >option, >> is memory management, since most libs use some sort of reference >counting. >> And you do not want to end up with nightmarish dozens of ref(bddNode) >> deref(bddNode) in your application code (like the probabilistic model >> checker PRISM does). This introduces hard to track bugs easily. >However, I >> have an idea in mind how to tackle this but I didn't found the time >to put >> it into code yet. >> >> May I ask, which sort of application do you have in mind? >> >> Best, Steffen >> >> >> >> >> Am .10.2017, 07:54 Uhr, schrieb Prof. Andrew P. Black ><black(a)cs.pdx.edu>: >> >>> Thanks for the responses so far. I see that I need to clarify my >enquiry. >>> >>> B-Trees and BDDs are not the same. BDDs are an efficient and >compact >>> representations for Boolean functions, sometimes used in SAT-solvers >and >>> electronics design. The key idea is that since the output must be >0 or 1, >>> you can represent any Boolean function as a tree whose depth is the >same as >>> the number of bits in the input. >>> >>> To make the tree small and efficient, though, you need to eliminate >any >>> node whose two children are the same, and to share subtrees, so that >you >>> really get a DAG, not a tree. The full name for these efficient >compressed >>> trees is âReduced Order Binary Decision Diagramsâ, or ROBDDs. I was >hoping >>> that someone else had implemented the algorithms necessary to build >this >>> representation. >>> >>> Because sets can be considered to be Booleans functions (true => >argument >>> is in the set), you can use ROBDDs to efficiently represent large >sets. >>> >>> To be clear, despite the word âdiagramâ in the name, one is not >normally >>> interested in drawing the BDD â except in the documentation for the >package >>> ;-). Normally, BDDs they are used to represent sets, or functions, >where >>> the drawing would be hopelessly large. >>> >>> The BuDDy package (http://buddy.sourceforge.net/manual/main.html) is >an >>> example of what Iâm looking for, but unfortunately itâs in C++. >>> >>> Andrew >>> >>> >>>> On 25 Oct 2017, at 21:39 , Stephane Ducasse ><stepharo.self(a)gmail.com> >>>> wrote: >>>> >>>> Hi andrew >>>> >>>> I think that Avi did a package about BDD (but I thought it was >special >>>> binary trees) so this is probably the same. >>>> Did you check on Squeaksource? >>>> http://www.squeaksource.com/BTree.html >>>> If this is what you are looking for I can help porting it to Pharo. >>>> >>>> Stef >>>> >>>> >>>> On Wed, Oct 25, 2017 at 9:02 PM, Prof. Andrew P. Black ><black(a)cs.pdx.edu> >>>> wrote: >>>>> >>>>> Does anyone know of a BDD â thatâs Binary Decision Diagram â >package >>>>> written in Smalltalk? >>>>> >>>>> Andrew >>>>> >>>>> >>>> >>> >>

Oct. 28, 2017

What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Hi, I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again). I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully. What is the idiomatic way to wait on SIGTERM and close the process gracefully? Thanks, Herby

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by CÃ©drick BÃ©ler

> ok for now publish your changes on smalltalkhub somewhere so that they > do not stay on your machine. Even if very very experimental :) Iâll do. Just need a bit more work and comment what I did. I have unsolved references to this classes too. DomBuilder IDBasicManager IDCurrentManager Any ideas ? Iâll read more carefully the white paper and see if XMLParser can help here. But is someone knows about this classesâ¦ Cheers, CÃ©drick > > On Sat, Oct 28, 2017 at 7:52 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> >>> >>> Did you send pull requests? >> >> Euh, actually I still donât really know how to use git. >> >> I loaded it through metacello. Can I simply a sunlit code that way ? >> >> The code is quite documented already and there are tests. >> >> I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). >> >> All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. >> >> And I still havenât find how to execute a process ^^ >> >> Iâll have another look today. >> >> Cheers, >> >> CÃ©drick >> >>> >>> Stef >>> >>>> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>>> A pleasure to discover ! To me, a wonderful(ly engineered) library. >>>> >>>> Big thanks to Netstyle ! >>>> >>>> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >>>> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >>>> >>>> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >>>> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >>>> >>>> Some stuffs that are missing: >>>> #isOmniBaseTransaction >>>> #markDirty >>>> A reference to TimeStamp fixed: >>>> #beginInHistory >>>> â¦ >>>> >>>> Need to fix WADynamicVariable with shouldnât be hard. >>>> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >>>> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >>>> >>>> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >>>> >>>> >>>> Cheers and thanks again, enligthening code :) >>>> >>>> CÃ©drick >>>> >>>> >>>> >>>> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >>>> >>>> >>>> >>>> >>>> >>>>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>>>> >>>>> Thank you! >>>>> >>>>> I thons this just perfect as a starting point ! >>>>> >>>>> Cheers, >>>>> >>>>> Cedrick >>>>> >>>>> EnvoyÃ© de mon iPhone >>>>> >>>>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>>>> >>>>>> Maybe the package described here has what you're looking for : >>>>>> >>>>>> http://forum.world.st/Ann-Workflow-td4963635.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> CÃ©drick BÃ©ler wrote >>>>>>> Hi again, this is my last question and the more general one of the day :-) >>>>>>> >>>>>>> >>>>>>> Iâm looking for way of representing and executing simple "business >>>>>>> processes" in Pharo and a way of declaring domain ontologies/taxonomies. >>>>>>> >>>>>>> I didnât find any lib around this subjects except some projects in other >>>>>>> smalltalk dialects. >>>>>>> >>>>>>> I just wander if somebody has done some work in these field. Iâm also >>>>>>> interested in (KISS) design discussions around these topics, hence this >>>>>>> email. >>>>>>> >>>>>>> I donât want to do a full fledged business process middleware. >>>>>>> >>>>>>> I would need : >>>>>>> - a way to represent simple business processes (succession of activities >>>>>>> with logic gates (and/or/xor) => I might be able to do that by myself). >>>>>>> - a way to execute these processes (routines) in a semi-aotumatic manner >>>>>>> => This looks more difficult to do to me. >>>>>>> => my aim is to execute recurrent routines (my routines) with the help of >>>>>>> a Pharo application >>>>>>> >>>>>>> >>>>>>> For such a system, I also need a way to categorize information context. >>>>>>> Again, I donât think I need a full fledged ontology implementation like >>>>>>> Description Logic (or whatever). I think Iâll be happy with information >>>>>>> tagging according to a predefined taxonomy. Instead of flat tags, Iâd like >>>>>>> them to implement some sort of multiple inheritance. For instance, I may >>>>>>> need a tag #soccer that "inherit" #sport. >>>>>>> >>>>>>> Any information regarding taxonomy tagging in Pharo ? (Or eventually >>>>>>> ontology?). >>>>>>> >>>>>>> >>>>>>> >>>>>>> TIA, >>>>>>> >>>>>>> CÃ©drick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>> >>>> >>> >> >

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

Hi andrew please take a project that would help to bring more companies and that you want to push and push it with us :). Stef On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi andrew > > you should contact esteban because he is writing an objective-C bridge. > > Stef > > On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> One thing Iâm working on is a bridge between Pharo and F-Script. >> F-Script is, basically, a Smalltalk dialect, as is obvious from the >> screenshot. However for MacOS and iOS, it allows you to bypass the static >> Objective-C API interface and debug / modify or even write applications >> directly in the system. To do that you âinjectâ F-Script into the OS. The >> ability to so has a specific implication, though. MacOS and iOS are >> themselves written in and as a dialect of Smalltalk. (were it simply an >> overlay on Objective-C, it wouldnât be able to do things that are >> impossible in Objective-C, and it wouldnât need to be âinjectedâ in order >> to run). Every implementation of Objective-C , bar GNUâs useless >> imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >> >> >> >> In any event, it will allow Pharo code to be mapped to MacOS and iOS >> objects, injected into the system dynamically, and modified / debugged >> dynamically using the Pharo tools. The result, at least as far as iOS is >> concerned, may make Pharo actually the most powerful way to program it, >> well beyond XCode alone, along with doing the same for MacOS. Android is >> another issue, although the Raspbian port of Pharo should be relatively >> easy to port to it. For me, unless someone had a use case, I donât have one >> myself for Android. Iâve tried nearly every version, because Iâd love to >> support an OSS ecosystem, unfortunately using it compared to the iPhone is >> still like driving a Fiero based kit car compared to an actual Ferrari. >> >> >> >> As far as JNI, while I see your point, JNI is such a PITA that few Java >> developers know it. My usual workaround is to use Stamp and Synapse, which >> has the further advantage of allowing Java to âthrottleâ data that the JVM >> canât deal with at full speed. >> >> >> >> As far as dealing with other JVM languages, PetitParser or SmaCC can >> generate bytecode rather than Java or other JVM code, and that allows libs >> to be written that utilize Synapse to talk to Pharo. It isnât necessarily >> an ideal solution, but a possible one without having to support umpteen >> environments. Another potential way of accomplishing that is to use >> NetRexx, a declarative JVM language, which is both easy and terse, and like >> SQL, generates the actual bytecode rather than precompiling to it. For >> instance, imagine the code needed for a simple âhello worldâ in Java, then >> compare: >> >> >> >> Say âhello worldâ >> >> >> >> Since it generates virtually the same bytecode, it may be an easy way to >> do it. >> >> >> >> With the last statement, that expresses really well the exact reason I no >> longer want to work in most other environments ð. >> >> >> >> Tc >> >> Andrew >> >> >> >> >> >> >> >> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >> Windows 10 >> >> >> >> *From: *phil(a)highoctane.be >> *Sent: *Thursday, October 26, 2017 2:19 AM >> *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> *Subject: *Re: [Pharo-users] Smalltalk Argument >> >> >> >> I like that piece a lot, seeing exactly the described situation in large >> enterprises. >> >> >> >> I made a strategic decision to go with Pharo for the long run for my >> solutions because it is a stable base on which to build (ok, there are >> evolutions, but fundamentally, I can rely on it being under control and can >> maintain solutions in a version). >> >> >> >> The rationale is that at a deep level I am really fed up with having to >> deal with accidental complexity (now having to deal with >> Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology >> drag and 20% net business contribution. >> >> >> >> One key thing is that a team needs guidance and Smalltalk makes it easier >> due to well known ways of doing things. >> >> >> >> Now we miss the boat on mobile and bigdata, but this is solvable. >> >> >> >> If we had an open Java bridge (and some people in the community have it >> for Pharo but do not open source it - so this is eminently doable) + Pharo >> as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we >> would have a way to embed Pharo in a lot of places (e.g. in the Hadoop >> ecosystem where fast starting VMs and small footprint would make the >> cluster capacity x2 or x3 vs uberjars all over the place) this would be a >> real disruption. >> >> >> >> Think about being able to call Pharo from JNA https://github.com/java-na >> tive-access/jna the same way we use C with UFFI. >> >> >> >> Smalltalk argument for me is that it makes development bearable (even fun >> and enjoyable would I say) vs the other stacks. That matters. >> >> >> >> Phil >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> >> wrote: >> >> Thereâs other questions that are relevant to me: >> >> >> >> Do I give a f*** about cool looking web apps? No, I donât use web apps >> if in any way I can avoid it. >> >> >> >> Do I give a f*** about mobile apps? No, the screenâs too small to read >> anything longer than a twit, or anyone with anything worthwhile to say. >> >> >> >> Do I give a f*** about the number of libraries in other languages? No, >> because most of them are crap in every language Iâve had to work in, and >> the base languages are crap so they have to keep changing radically, and >> libraries and frameworks therefore also have to and never get any better. >> The few that are worthwhile I can almost always use from Smalltalk without >> a problem (read, Blender, ACT-R and Synapse, since every other >> library/framework Iâve used outside Smalltalk has been a waste of time). >> >> >> >> Do I give a f*** about implementing a complex piece of machine learning >> software in 22 hours, compared to 3 months for the Java version? Well, >> actually yes, I do, because that was 3 months of my life down the toilet >> for something that is too slow to be useful in Java. >> >> >> >> Any argument depends on your priorities. Iâve written tons of web apps, >> because I needed to get paid. Iâve written better shitty mobile apps than >> the average shitty mobile apps. However, Iâm not going to do any of that >> any longer in crap that never improves, because after 26 years the >> irritability it produces is more than itâs worth. >> >> >> >> A few weeks ago, a recruiter that specializes in Smalltalk called me >> about a job, although they were well aware I live 1500 miles away from the >> city I lived in when I had worked through them, to see if Iâd be willing to >> move back there for a job. That sounds like another âthere arenât enough >> Smalltalk developersâ, but it wasnât, because the job wasnât writing >> Smalltalk. It was writing Java. >> >> >> >> The person hiring, though, wouldnât look at anyone who didnât write >> Smalltalk, because âpeople who grew up with Java donât know how to write >> codeâ. I donât agree with that, Iâve known a (very few) good Java >> developers. I would say, though, that Iâve known far more incompetent ones >> than good ones, and I canât think of any incompetent Smalltalk developers >> off the top of my head. >> >> >> >> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or >> even C, complain about how hard maintaining state is or coming up with >> various hacks to avoid it, which seems to be the main point of every >> JavaScript based âtechnologyâ. An application is by definition a >> state-machine, which implies plenty about JS developers on the whole. >> >> >> >> If youâre a good developer you can write good code in (nearly) anything. >> My question then is why would you want to write in crap? The better >> question is why arenât there more good developers in *any* language? >> >> >> >> Every project I have been able to do in Smalltalk, though, has had one >> thing in common, the âshit has to workâ. Companies do use it, in fact I >> could name 4 large enterprises Iâve worked for whoâve written their own >> dialects, and they all use it only when âshit has to workâ. They know itâs >> more productive, they also know using it for more things would increase the >> availability of Smalltalk developers. >> >> >> >> Why do they not do it? One reason, though it takes a while to recognize >> it, because management doesnât admit even to themselves why they do it, or >> not very often. Being inefficient, as long as it doesnât âreallyâ matter, >> is an advantage to large enterprises because they have resources smaller >> competitors donât. >> >> >> >> Why donât their competitors do it? Because they canât see past an hourly >> rate, whatâs fashionable, or just new, or because their customers canât. >> Put more generally, average stupidity that isnât corrected by the market. >> Fashion affects smaller companies more than larger ones, because they canât >> afford a few customers walking away because they wanted an app in Electron, >> even if they canât give any relevant reason for wanting it, and even the >> samples on the Electron site donât work. >> >> >> >> Enterprises can, and do use Smalltalk when it matters. When it doesnât, >> itâs to their advantage to promote things that are inefficient, buggy and >> unreliable. >> >> >> >> Cost is relevant, but not in the simple way people look at things. A >> crucial but rarely mentioned perspective on its relevance is that while >> Java based software runs TV set top boxes, Smalltalk based software runs >> things like medical equipment, automated defense systems, tanks, etc. Cost >> becomes largely irrelevant when âshit has to workâ. >> >> >> >> Productivity is primarily relevant to less talented developers, in an >> inversely sense, since unproductive environments and attitudes have a >> leveling tendency in general, and more specifically make accomplishing what >> the less talented are capable of in any environment sufficiently laborious >> for them to have a role. Capability in Smalltalk, as implied by the person >> hiring for the Java role I mentioned, is a fairly decent means of judging >> whether someone is a so-so developer or a good one. >> >> >> >> The productivity argument is realistically only relevant in the context >> of an already higher hourly cost. Given that it is relevant at that point, >> companies that know Smalltalk is more productive would use it outside >> things that have to be 100%, *if* their own productivity were relevant >> to the same degree that competitorsâ productivity is inversely relevant. >> >> >> >> All these ways of looking at it are contingent perspectives though. Yes, >> if the number of libraries is relevant to you, Smalltalk is less >> attractive, but thatâs only a contingent phenomenon based on the relative >> popularity of Java and JavaScript, as a result it canât be used as >> explanatory *for* that popularity. All the ways of looking at it that >> are fully determinate are determinate via contingencies of that kind, which >> for the most part *are* precisely the other perspectives, including >> productivity, cost, availability of developers, etc. None of them is *in >> itself* anything but a result of the others. >> >> >> >> If availability of developers is contingent on popularity (and further, >> popularity contingent on industry attitudes), to use an example already >> mentioned in Joachimâs post, then his simultaneous posit of library >> availability is if anything more contingent on the same popularity, so >> positing it as a cause and not a result, or merely a correlate, of >> popularity is incoherent. We can go one step further, and demonstrate that >> even when large enterprises make something that works reliably available, >> they fail to promote and support it, which destroys the market for reliable >> tooling by simultaneously owning it while not promoting it, something IBM >> is particularly good at. But IBM canât (and if they canât, neither can any >> other company) operate that way without the tacit agreement of the >> industry. >> >> >> >> To understand it in a more general way, software development has to be >> looked at in the context where it occurs, and how itâs determined to a >> large degree by that context, with a specific difference. That difference >> is itself implicit in the context, i.e. capitalism, but only *purely *effective >> in software development. Itâs a result of virtualization as an implicit >> goal of capitalism, and the disruptions implicit in the virtual but so far >> only realized completely in software. In terms of that understanding, the >> analysis of virtualization and disruption as inherent to capitalism is >> better accomplished in Kapital than in any more recent work. >> >> >> >> Or you can simply decide, as Iâve done recently, that working in ways and >> with tools that prevent doing good work in a reasonable timeframe isnât >> worthwhile *to you,* no matter how popular those ways and tools might >> be, or what the posited reasons are, since at the end popularity is only >> insofar as it *already* is. What those tools and methods are depends to >> a degree on your priorities, but if developers are *engineers* those >> priorities canât be completely arbitrary. Engineers are defined by their >> ability to make things work. >> >> >> >> Software as virtual is inherently disruptive, and the software industry >> disrupts itself too often and too easily to build on anything. A further >> disruption caused by developers, *as* engineers, refusing to work with >> crap that *doesnât*, i.e. insisting on being engineers, while in itself >> merely an aggravation of the disruptive tendencies, might have an inverse >> result. >> >> >> >> Using a stable core of technologies as the basis for a more volatile set >> of products, in the way nearly every other industry does, is the best means >> we know of to build things both flexibly and reasonably efficiently. The >> computer hardware industry is the extreme example of this, while the >> software industry is the extreme contradiction. >> >> >> >> *From: *Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of >> David Mason <dmason(a)ryerson.ca> >> *Reply-To: *Any question about pharo is welcome < >> pharo-users(a)lists.pharo.org> >> *Date: *Tuesday, October 24, 2017 at 11:52 AM >> *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> *Subject: *Re: [Pharo-users] Smalltalk Argument >> >> >> >> PharoJS is working to give you that mobile app/browser app experience. >> As with others, we're not there yet, but getting there. See >> http://pharojs.org >> >> >> >> The 67% loved means that 67% of people using Smalltalk (or perhaps have >> ever used it) want to continue - so it's presumably a high percentage of a >> smallish number of people. >> >> >> >> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < >> jtuchel(a)objektfabrik.de> wrote: >> >> First of all: I'd say the question itself is not a question but an >> excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I >> think the question is just a way of saying "we don't want to do it for >> reasons that we ourselves cannot really express". If you are a good >> developer, learning Smalltalk is easy. If you are a good developer you've >> heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at >> least twice a year. So you most likely would like to learn it anyways. >> >> A shortage of developers doesn't exist. What exists is an unwillingness >> of companies to get people trained in a technology. If Smalltalk was cool >> and great in their opinion, they wouldn't care. It's that simple. As a >> consultant, I've heard that argument so often. Not ferom Startups, but from >> insurance companies, Banks or Car manufacturers who spend millions on >> useless, endless meetings and stuff instead of just hiring somebody to >> teach a couple of developers Smalltalk. It's just a lie: the shortage of >> Smalltalk developers is not a problem. >> >> And, to be honest: what is it we actually are better in by using >> Smalltalk? >> Can we build cool looking web apps in extremely short time? No. >> Can we build mobile Apps with little effort? No. >> Does our Smalltalk ship lots of great libraries for all kinds of things >> that are not availabel in similar quality in any other language? >> Are we lying when we say we are so extremely over-productive as compared >> to other languages? >> >> I know, all that live debugging stuff and such is great and it is much >> faster to find & fix a bug in Smalltalk than in any other environment I've >> used so far. But that is really only true for business code. When I need to >> connect to things or want to build a modern GUI or a web application with a >> great look&feel, I am nowhere near productive, because I simply have to >> build my own stuff or learn how to use other external resources. If I want >> to build something for a mobile device, I will only hear that somebody >> somewhere has done it before. No docs, no proof, no ready-made tool for me. >> >> >> Shortage of developers is not really the problem. If Smalltalk was as >> cool as we like to make ourselves believe, this problem would be >> non-existent. If somebody took out their iPad and told an audience: "We did >> this in Smalltalk in 40% of the time it would have taken in Swift", and if >> that something was a must-have for people, things would be much easier. But >> nobody has. >> >> >> I am absolutely over-exaggerating, because I make my living with an SaaS >> product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk >> and - as you - am convince that many parts of what we've done so far >> would've taken much longer or even be impossible in other languages. But >> the advantage was eaten by our extremely steep learning curve for web >> technologies and for building something that works almost as well as tools >> like Angular or jQuery Mobile. >> >> Smalltalk is cool, and the day somebody shows me something like Google's >> flutter in Smalltalk, I am ready to bet a lot on a bright future for >> Smalltalk. But until then, I'd say these arguments about productivity are >> just us trying to make ourselves believe we're still the top of the food >> chain. We've done that for almost thirty years now and still aren't ready >> to stop it. But we've been lying to ourselves and still do so. >> >> I don't think there is a point in discussing about the usefulness of a >> language using an argument like the number or ready-made developers. That >> is just an argument they know you can't win. The real question is and >> should be: what is the benefit of using Smalltalk. Our productivity >> argument is a lie as soon as we have to build something that uses or runs >> on technology that has been invented after 1990. >> >> >> Okay, shoot ;-) >> >> Joachim >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> >> >> >> >> >> > >

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

Hi andrew you should contact esteban because he is writing an objective-C bridge. Stef On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > One thing Iâm working on is a bridge between Pharo and F-Script. F-Script > is, basically, a Smalltalk dialect, as is obvious from the screenshot. > However for MacOS and iOS, it allows you to bypass the static Objective-C > API interface and debug / modify or even write applications directly in the > system. To do that you âinjectâ F-Script into the OS. The ability to so > has a specific implication, though. MacOS and iOS are themselves written > in and as a dialect of Smalltalk. (were it simply an overlay on > Objective-C, it wouldnât be able to do things that are impossible in > Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every > implementation of Objective-C , bar GNUâs useless imitation, compiles to > Smalltalk. No surprise that Appleâs does, as well. > > > > In any event, it will allow Pharo code to be mapped to MacOS and iOS > objects, injected into the system dynamically, and modified / debugged > dynamically using the Pharo tools. The result, at least as far as iOS is > concerned, may make Pharo actually the most powerful way to program it, > well beyond XCode alone, along with doing the same for MacOS. Android is > another issue, although the Raspbian port of Pharo should be relatively > easy to port to it. For me, unless someone had a use case, I donât have one > myself for Android. Iâve tried nearly every version, because Iâd love to > support an OSS ecosystem, unfortunately using it compared to the iPhone is > still like driving a Fiero based kit car compared to an actual Ferrari. > > > > As far as JNI, while I see your point, JNI is such a PITA that few Java > developers know it. My usual workaround is to use Stamp and Synapse, which > has the further advantage of allowing Java to âthrottleâ data that the JVM > canât deal with at full speed. > > > > As far as dealing with other JVM languages, PetitParser or SmaCC can > generate bytecode rather than Java or other JVM code, and that allows libs > to be written that utilize Synapse to talk to Pharo. It isnât necessarily > an ideal solution, but a possible one without having to support umpteen > environments. Another potential way of accomplishing that is to use > NetRexx, a declarative JVM language, which is both easy and terse, and like > SQL, generates the actual bytecode rather than precompiling to it. For > instance, imagine the code needed for a simple âhello worldâ in Java, then > compare: > > > > Say âhello worldâ > > > > Since it generates virtually the same bytecode, it may be an easy way to > do it. > > > > With the last statement, that expresses really well the exact reason I no > longer want to work in most other environments ð. > > > > Tc > > Andrew > > > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *phil(a)highoctane.be > *Sent: *Thursday, October 26, 2017 2:19 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > I like that piece a lot, seeing exactly the described situation in large > enterprises. > > > > I made a strategic decision to go with Pharo for the long run for my > solutions because it is a stable base on which to build (ok, there are > evolutions, but fundamentally, I can rely on it being under control and can > maintain solutions in a version). > > > > The rationale is that at a deep level I am really fed up with having to > deal with accidental complexity (now having to deal with > Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology > drag and 20% net business contribution. > > > > One key thing is that a team needs guidance and Smalltalk makes it easier > due to well known ways of doing things. > > > > Now we miss the boat on mobile and bigdata, but this is solvable. > > > > If we had an open Java bridge (and some people in the community have it > for Pharo but do not open source it - so this is eminently doable) + Pharo > as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we > would have a way to embed Pharo in a lot of places (e.g. in the Hadoop > ecosystem where fast starting VMs and small footprint would make the > cluster capacity x2 or x3 vs uberjars all over the place) this would be a > real disruption. > > > > Think about being able to call Pharo from JNA https://github.com/java- > native-access/jna the same way we use C with UFFI. > > > > Smalltalk argument for me is that it makes development bearable (even fun > and enjoyable would I say) vs the other stacks. That matters. > > > > Phil > > > > > > > > > > > > > > > > > > On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > > Thereâs other questions that are relevant to me: > > > > Do I give a f*** about cool looking web apps? No, I donât use web apps if > in any way I can avoid it. > > > > Do I give a f*** about mobile apps? No, the screenâs too small to read > anything longer than a twit, or anyone with anything worthwhile to say. > > > > Do I give a f*** about the number of libraries in other languages? No, > because most of them are crap in every language Iâve had to work in, and > the base languages are crap so they have to keep changing radically, and > libraries and frameworks therefore also have to and never get any better. > The few that are worthwhile I can almost always use from Smalltalk without > a problem (read, Blender, ACT-R and Synapse, since every other > library/framework Iâve used outside Smalltalk has been a waste of time). > > > > Do I give a f*** about implementing a complex piece of machine learning > software in 22 hours, compared to 3 months for the Java version? Well, > actually yes, I do, because that was 3 months of my life down the toilet > for something that is too slow to be useful in Java. > > > > Any argument depends on your priorities. Iâve written tons of web apps, > because I needed to get paid. Iâve written better shitty mobile apps than > the average shitty mobile apps. However, Iâm not going to do any of that > any longer in crap that never improves, because after 26 years the > irritability it produces is more than itâs worth. > > > > A few weeks ago, a recruiter that specializes in Smalltalk called me about > a job, although they were well aware I live 1500 miles away from the city I > lived in when I had worked through them, to see if Iâd be willing to move > back there for a job. That sounds like another âthere arenât enough > Smalltalk developersâ, but it wasnât, because the job wasnât writing > Smalltalk. It was writing Java. > > > > The person hiring, though, wouldnât look at anyone who didnât write > Smalltalk, because âpeople who grew up with Java donât know how to write > codeâ. I donât agree with that, Iâve known a (very few) good Java > developers. I would say, though, that Iâve known far more incompetent ones > than good ones, and I canât think of any incompetent Smalltalk developers > off the top of my head. > > > > Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or > even C, complain about how hard maintaining state is or coming up with > various hacks to avoid it, which seems to be the main point of every > JavaScript based âtechnologyâ. An application is by definition a > state-machine, which implies plenty about JS developers on the whole. > > > > If youâre a good developer you can write good code in (nearly) anything. > My question then is why would you want to write in crap? The better > question is why arenât there more good developers in *any* language? > > > > Every project I have been able to do in Smalltalk, though, has had one > thing in common, the âshit has to workâ. Companies do use it, in fact I > could name 4 large enterprises Iâve worked for whoâve written their own > dialects, and they all use it only when âshit has to workâ. They know itâs > more productive, they also know using it for more things would increase the > availability of Smalltalk developers. > > > > Why do they not do it? One reason, though it takes a while to recognize > it, because management doesnât admit even to themselves why they do it, or > not very often. Being inefficient, as long as it doesnât âreallyâ matter, > is an advantage to large enterprises because they have resources smaller > competitors donât. > > > > Why donât their competitors do it? Because they canât see past an hourly > rate, whatâs fashionable, or just new, or because their customers canât. > Put more generally, average stupidity that isnât corrected by the market. > Fashion affects smaller companies more than larger ones, because they canât > afford a few customers walking away because they wanted an app in Electron, > even if they canât give any relevant reason for wanting it, and even the > samples on the Electron site donât work. > > > > Enterprises can, and do use Smalltalk when it matters. When it doesnât, > itâs to their advantage to promote things that are inefficient, buggy and > unreliable. > > > > Cost is relevant, but not in the simple way people look at things. A > crucial but rarely mentioned perspective on its relevance is that while > Java based software runs TV set top boxes, Smalltalk based software runs > things like medical equipment, automated defense systems, tanks, etc. Cost > becomes largely irrelevant when âshit has to workâ. > > > > Productivity is primarily relevant to less talented developers, in an > inversely sense, since unproductive environments and attitudes have a > leveling tendency in general, and more specifically make accomplishing what > the less talented are capable of in any environment sufficiently laborious > for them to have a role. Capability in Smalltalk, as implied by the person > hiring for the Java role I mentioned, is a fairly decent means of judging > whether someone is a so-so developer or a good one. > > > > The productivity argument is realistically only relevant in the context of > an already higher hourly cost. Given that it is relevant at that point, > companies that know Smalltalk is more productive would use it outside > things that have to be 100%, *if* their own productivity were relevant to > the same degree that competitorsâ productivity is inversely relevant. > > > > All these ways of looking at it are contingent perspectives though. Yes, > if the number of libraries is relevant to you, Smalltalk is less > attractive, but thatâs only a contingent phenomenon based on the relative > popularity of Java and JavaScript, as a result it canât be used as > explanatory *for* that popularity. All the ways of looking at it that > are fully determinate are determinate via contingencies of that kind, which > for the most part *are* precisely the other perspectives, including > productivity, cost, availability of developers, etc. None of them is *in > itself* anything but a result of the others. > > > > If availability of developers is contingent on popularity (and further, > popularity contingent on industry attitudes), to use an example already > mentioned in Joachimâs post, then his simultaneous posit of library > availability is if anything more contingent on the same popularity, so > positing it as a cause and not a result, or merely a correlate, of > popularity is incoherent. We can go one step further, and demonstrate that > even when large enterprises make something that works reliably available, > they fail to promote and support it, which destroys the market for reliable > tooling by simultaneously owning it while not promoting it, something IBM > is particularly good at. But IBM canât (and if they canât, neither can any > other company) operate that way without the tacit agreement of the > industry. > > > > To understand it in a more general way, software development has to be > looked at in the context where it occurs, and how itâs determined to a > large degree by that context, with a specific difference. That difference > is itself implicit in the context, i.e. capitalism, but only *purely *effective > in software development. Itâs a result of virtualization as an implicit > goal of capitalism, and the disruptions implicit in the virtual but so far > only realized completely in software. In terms of that understanding, the > analysis of virtualization and disruption as inherent to capitalism is > better accomplished in Kapital than in any more recent work. > > > > Or you can simply decide, as Iâve done recently, that working in ways and > with tools that prevent doing good work in a reasonable timeframe isnât > worthwhile *to you,* no matter how popular those ways and tools might be, > or what the posited reasons are, since at the end popularity is only > insofar as it *already* is. What those tools and methods are depends to > a degree on your priorities, but if developers are *engineers* those > priorities canât be completely arbitrary. Engineers are defined by their > ability to make things work. > > > > Software as virtual is inherently disruptive, and the software industry > disrupts itself too often and too easily to build on anything. A further > disruption caused by developers, *as* engineers, refusing to work with > crap that *doesnât*, i.e. insisting on being engineers, while in itself > merely an aggravation of the disruptive tendencies, might have an inverse > result. > > > > Using a stable core of technologies as the basis for a more volatile set > of products, in the way nearly every other industry does, is the best means > we know of to build things both flexibly and reasonably efficiently. The > computer hardware industry is the extreme example of this, while the > software industry is the extreme contradiction. > > > > *From: *Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of > David Mason <dmason(a)ryerson.ca> > *Reply-To: *Any question about pharo is welcome < > pharo-users(a)lists.pharo.org> > *Date: *Tuesday, October 24, 2017 at 11:52 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > PharoJS is working to give you that mobile app/browser app experience. As > with others, we're not there yet, but getting there. See > http://pharojs.org > > > > The 67% loved means that 67% of people using Smalltalk (or perhaps have > ever used it) want to continue - so it's presumably a high percentage of a > smallish number of people. > > > > On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < > jtuchel(a)objektfabrik.de> wrote: > > First of all: I'd say the question itself is not a question but an excuse. > I am not arguing there are enough Smalltalkers or cheap ones. But I think > the question is just a way of saying "we don't want to do it for reasons > that we ourselves cannot really express". If you are a good developer, > learning Smalltalk is easy. If you are a good developer you've heard the > sentence "we've taken the goos parts from x,y,z and Smalltalk" at least > twice a year. So you most likely would like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an unwillingness of > companies to get people trained in a technology. If Smalltalk was cool and > great in their opinion, they wouldn't care. It's that simple. As a > consultant, I've heard that argument so often. Not ferom Startups, but from > insurance companies, Banks or Car manufacturers who spend millions on > useless, endless meetings and stuff instead of just hiring somebody to > teach a couple of developers Smalltalk. It's just a lie: the shortage of > Smalltalk developers is not a problem. > > And, to be honest: what is it we actually are better in by using Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of things > that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as compared > to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment I've > used so far. But that is really only true for business code. When I need to > connect to things or want to build a modern GUI or a web application with a > great look&feel, I am nowhere near productive, because I simply have to > build my own stuff or learn how to use other external resources. If I want > to build something for a mobile device, I will only hear that somebody > somewhere has done it before. No docs, no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as cool > as we like to make ourselves believe, this problem would be non-existent. > If somebody took out their iPad and told an audience: "We did this in > Smalltalk in 40% of the time it would have taken in Swift", and if that > something was a must-have for people, things would be much easier. But > nobody has. > > > I am absolutely over-exaggerating, because I make my living with an SaaS > product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk > and - as you - am convince that many parts of what we've done so far > would've taken much longer or even be impossible in other languages. But > the advantage was eaten by our extremely steep learning curve for web > technologies and for building something that works almost as well as tools > like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like Google's > flutter in Smalltalk, I am ready to bet a lot on a bright future for > Smalltalk. But until then, I'd say these arguments about productivity are > just us trying to make ourselves believe we're still the top of the food > chain. We've done that for almost thirty years now and still aren't ready > to stop it. But we've been lying to ourselves and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. That > is just an argument they know you can't win. The real question is and > should be: what is the benefit of using Smalltalk. Our productivity > argument is a lie as soon as we have to build something that uses or runs > on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > > > > >

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

On Sat, Oct 28, 2017 at 6:10 AM Andrew Glynn <aglynn42(a)gmail.com> wrote: > Web dev is a messy field. Not because it has grown too fast, but because > it was designed by amateurs, developed by amateurs, and continues to be so, > while depending on an underlying expertly designed system, the internet. > Non sense. Companies have been heavily involved in the developing of the web since day one. Javascript was not designed by an amateur and pretty much no web dev technologies out there not only are produced since day 1 from professional coders , web standards committess played a crucial role in the developing of web technologies. The web has always been a huge cash cow. The very fact that Javascript has the name Java is not as many developers will be quick to point unrelated Java. It is very much related. . Sun for a considerable amount of time was working on Javascript as a scripting engine targeting the web working hand in hand with Java. The relationship was sort lived but for a very long time Java was the de facto language for developing powerful web application / websites. The well known Java applets that exist even today. The reason why the web followed its own road is quite sensible. The internet was viewed as nothing more than a display of documents and made sense to use a document format (HTML) for it at the time. It was easy and accesible to anyone. None could predict the explosion of the web at the time and the future needs for much greater degree of dynamism. Neither could I and I am vicious critic of web dev. The technology evolved very fast that not even up for debate, good designs require redesigns. Redesigns require time. The web was nothing really new neither was the internet. BBS were dominating online communication and function in a very similar way that the web did later on providing, email, messages, forumes, download directories, blog posts, articles and a wealth of information through the use of a model and a regular telophone line. BBS were based on desktop technology and far better designed but they could not keep up with the incrasing demands of massive online communication so the web and the internet ignated even though internet was create far earlier than BBS. Much less likely to find cat videos because BBS was based on P2P kind of technology and was working on very limited hardware where every byte was precious. It was the failure of desktop technologies to adjust to the need for a web that lead to its seperate evolution. Java was the only language that took a serious interest into web developing and even Java was unwilling to adjust to the needs of the web leading to the massive failure of the Java applet. On the other hand Flash that was specifically designed for the web , flourished for many years till HTML and JS finally caught up. Amateurs also play a very importan role in the evolution of graphics and guis. Teenage hackers were the ones to ignite the trend of computer graphics that lead to the establishment of GUI and 3d graphics as well as computer audio even though those technologies have existed far earlier it was their innovation that managed to take advantage of clever solution to overcome extreme limitations of the hardware. This happened through the developing of "demos" giving rise to a completely new community of extrmely knowledgable amateurs knows as "demoscene" and hackers. 3d graphics to this day remain the most fast moving / evolving field of computer science challanged only by AI. Plus Amateurs play a vital role in many other fields like Astronomy , their contribution is so substabtial that many celestial bodies are named after them. Amateurs have usually far higher level of knowledge of a field mainly because they tend to avoid specialisation and they do not operate on the time constraints or have to fight a backward thinking management department that want to do things "the popular" way. For similar reason they pay far more respect to designs as well. So it was both the failure of desktop to take into serious consideration the new web needs and the rapid evolution of the web based on the format that it was already problematic. It was companies themselves that hindered and keep hindering its evolution with being stuck on bad design for the shake of backward compatibility. On the other hand desktop has it own share of ugliness and "amateurism" biggest example being MFC , Microsoft's Official GUI API, that was so ugly and heavily disliked that none even question the existence of HTML because no coder in his right mind could consider imposing such a terrible design to a new technology. On similar note web is not all that bad, JS has heavily improved as a language , HTML has become extremely flexible and there are many well designed libraries like Bootstrap , D3 etc . Also desktop language learned their lesson and now fully embreace web dev at least on the back end. Finally nowdays we see the merging of web and desktop technlogies (and the branch of desktop development known as "mobile development") that has brought more sanity and uniformity into the development process. Unfortunately companies still play a very big role in the glacial evolution of the web that is fortunately dimisihing with the emergence of free software.

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by Stephane Ducasse

ok for now publish your changes on smalltalkhub somewhere so that they do not stay on your machine. On Sat, Oct 28, 2017 at 7:52 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > >> >> Did you send pull requests? > > Euh, actually I still donât really know how to use git. > > I loaded it through metacello. Can I simply a sunlit code that way ? > > The code is quite documented already and there are tests. > > I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). > > All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. > > And I still havenât find how to execute a process ^^ > > Iâll have another look today. > > Cheers, > > CÃ©drick > >> >> Stef >> >>> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>> A pleasure to discover ! To me, a wonderful(ly engineered) library. >>> >>> Big thanks to Netstyle ! >>> >>> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >>> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >>> >>> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >>> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >>> >>> Some stuffs that are missing: >>> #isOmniBaseTransaction >>> #markDirty >>> A reference to TimeStamp fixed: >>> #beginInHistory >>> â¦ >>> >>> Need to fix WADynamicVariable with shouldnât be hard. >>> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >>> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >>> >>> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >>> >>> >>> Cheers and thanks again, enligthening code :) >>> >>> CÃ©drick >>> >>> >>> >>> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >>> >>> >>> >>> >>> >>>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>>> >>>> Thank you! >>>> >>>> I thons this just perfect as a starting point ! >>>> >>>> Cheers, >>>> >>>> Cedrick >>>> >>>> EnvoyÃ© de mon iPhone >>>> >>>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>>> >>>>> Maybe the package described here has what you're looking for : >>>>> >>>>> http://forum.world.st/Ann-Workflow-td4963635.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> CÃ©drick BÃ©ler wrote >>>>>> Hi again, this is my last question and the more general one of the day :-) >>>>>> >>>>>> >>>>>> Iâm looking for way of representing and executing simple "business >>>>>> processes" in Pharo and a way of declaring domain ontologies/taxonomies. >>>>>> >>>>>> I didnât find any lib around this subjects except some projects in other >>>>>> smalltalk dialects. >>>>>> >>>>>> I just wander if somebody has done some work in these field. Iâm also >>>>>> interested in (KISS) design discussions around these topics, hence this >>>>>> email. >>>>>> >>>>>> I donât want to do a full fledged business process middleware. >>>>>> >>>>>> I would need : >>>>>> - a way to represent simple business processes (succession of activities >>>>>> with logic gates (and/or/xor) => I might be able to do that by myself). >>>>>> - a way to execute these processes (routines) in a semi-aotumatic manner >>>>>> => This looks more difficult to do to me. >>>>>> => my aim is to execute recurrent routines (my routines) with the help of >>>>>> a Pharo application >>>>>> >>>>>> >>>>>> For such a system, I also need a way to categorize information context. >>>>>> Again, I donât think I need a full fledged ontology implementation like >>>>>> Description Logic (or whatever). I think Iâll be happy with information >>>>>> tagging according to a predefined taxonomy. Instead of flat tags, Iâd like >>>>>> them to implement some sort of multiple inheritance. For instance, I may >>>>>> need a tag #soccer that "inherit" #sport. >>>>>> >>>>>> Any information regarding taxonomy tagging in Pharo ? (Or eventually >>>>>> ontology?). >>>>>> >>>>>> >>>>>> >>>>>> TIA, >>>>>> >>>>>> CÃ©drick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>> >>> >> >

Oct. 28, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Tudor Girba

Great work! Doru > On Oct 27, 2017, at 11:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit for latest changes. > This version has an important amount of tweak and fixes, but most important is the inclusion of tonel file format (this is default for Pharo 7.0, optional for Pharo 6.1) and introduces a file-per-class format. > The advantages of this format has everything to do with the speed of access (is easier to reconstruct a package like) and the space on disk (methods are usually small but minimum space in disk is usually 4k so we waste a lot of space). Is also a better format for SSD disks. > > To backport Iceberg 0.6.2 I also needed to backport latest version of Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of it available :) > > cheers! > Esteban > > > > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Oct. 28, 2017