Resolving package names...
Locked
12
12
RE: Resolving package names...
 
|
Ah, but our point is that StORE *already* has tools in place to do it,
see "Edit Bundle Spec..." -> "Validate", all we're pushing for is making that validation mandatory for publishing or at least a warning dialog with confirmation... Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Rick Flower [mailto:[hidden email]] > Sent: Monday, April 02, 2007 8:59 AM > To: [hidden email] > Subject: Re: Resolving package names... > > Joerg Beekmann wrote: > > And I'm positive I don't know my own mind on the issue in general; > > HOWEVER I do know I have no use for a stored bundle that can't be > > loaded! None, zero... does anyone else? If not not can we agree that > > fact that store allows you to do this is a bug? Our fix is quite simple, > > run sTORE's own validation prior to storing. > > In my case, my manual validation was to store the bundle in question > into my Store repository, save my image, then unload the bundle and > try to re-load it from the repository.. If it didn't work, then exit the > image and start up again and fix the unresolved issue.. I did that > several times and it eventually ferreted out all of the problems. |
|
|
Boris Popov wrote:
> Ah, but our point is that StORE *already* has tools in place to do it, > see "Edit Bundle Spec..." -> "Validate", all we're pushing for is making > that validation mandatory for publishing or at least a warning dialog > with confirmation... Ahh.. Sorry for being dense.. I guess I missed that one. I would agree that it would be excellent to have Store validate it for me to diagnose obvious problems that I would otherwise catch at re-load time.. I guess this topic has also been well flogged at this point. Regardless, I'll check out the validate feature next time I've got my image up-n-running! |
RE: Resolving package names...
|
|
In reply to this post by Rick Flower
Indeed and it is a hassle. I'm a bit puzzled as to why no one else sees it this way. Just think of the Bundle as document and Publish as the save action. If any other application rquired you to press the "Validate" button to ensure that the the document you were saving could be opened later users would object. In this case they don't seem to. Joerg > -----Original Message----- > From: Rick Flower [mailto:[hidden email]] > Sent: April 2, 2007 8:59 AM > To: [hidden email] > Subject: Re: Resolving package names... > > Joerg Beekmann wrote: > > And I'm positive I don't know my own mind on the issue in general; > > HOWEVER I do know I have no use for a stored bundle that can't be > > loaded! None, zero... does anyone else? If not not can we > agree that > > the fact that store allows you to do this is a bug? Our fix > is quite > > simple, run sTORE's own validation prior to storing. > > In my case, my manual validation was to store the bundle in > question into my Store repository, save my image, then unload > the bundle and try to re-load it from the repository.. If it > didn't work, then exit the image and start up again and fix > the unresolved issue.. I did that several times and it > eventually ferreted out all of the problems. > > |
Re: Resolving package names...
|
|
In reply to this post by Joachim Geidel
On Apr 1, 2007, at 1:49, Joachim Geidel wrote:
Joachim, I shot off this message and then left for nearly a week of wonderful spring skiing. Looking back... I'm very sorry. It was meant to sound rude or patronizing, though in retrospect it does. And I'm sorry. We probably agree about more than it sounds like and are just focusing on details. Rather than argue about specific implementation detials, the points I would focus on are two: 1) Smalltalk has a history of being different, sometimes just for the sake of being different. I am not accusing you at all of being this way. Or anyone else in particular. It is human nature to look at any solution, and for a variety of reasons, conclude that it doesn't apply to us. It is that reaction that I would guard against in a debate about "how to manage code." Analogies never scale. But concepts and abstractions are often reusable to some degree. 2) The simpler said system is, the better it scales. It is easier to build tools for and turn into interesting and useful things. Simple but elegant building blocks. We have no further to look than the core of Smalltalk itself (not necessarily some of the artifacts built with it) to have seen how well this can play out. Bundles being the usual example (though not only) that I usually use to prat about Store, maybe I err in trying to disprove their necessity by comparisons to other systems. Maybe it'd just be easier to ask: Can anyone disprove that all of the tools in the IDE would be easier to write, maintain, improve, extend, if it weren't for the duplicity presented by bundles. Has anyone out there ever written a tool where having to deal with bundles and packages and pundles, made the job easier? -- Travis Griggs Objologist "Only one thing is impossible for God: to find any sense in any copyright law on the planet." - Mark Twain |
Re: Resolving package names...
|
|
On Apr 6, 2007, at 18:51, Travis Griggs wrote:
GAH!!!! ...It WAS NOT meant to sound... Sorry 2x now. :) -- Travis Griggs Objologist "HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup of coffee at the same time." - Martin Kobetic |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |