Two store questions
Locked
123
123
 
|
Good morning everybody,
I have two questions: 1. Is there a way or tool to find out the package/bundle prerequisites before actually loading it ? 2. Recently me and my colleague were working on the same package, and we did published the same package within a minutes from each other. The end result of it we now have to version of the same package with the identical version. That situation did happened only couple of times over three years using store, but still is there any automated way to prevent this from happening again ? It look s like the "version" is just a varChar field on the package table , so I was thinking about putting a unique constraint on it, but then it will fail on the commit and I have to handle the commit failure . Any Ideas anyone ? Truly, --Mark Pirogovsky |
Re: Two store questions
|
|
Mark:
For example: (Store.Package allVersionsWithName: 'MyPackage') first developmentPrerequisites there may be a more direct way but I did verified that in a basically virgin image i.e. MyPackage was not loaded , that it did provide me with the pre-reqs. hth, -Charles On Thu, 23 Feb 2006 12:03:27 -0500, Mark Pirogovsky <[hidden email]> wrote: self developmentPrerequisites > Good morning everybody, > > I have two questions: > > 1. Is there a way or tool to find out the package/bundle prerequisites > before actually loading it ? > > 2. Recently me and my colleague were working on the same package, and > we did published the same package within a minutes from each other. The > end result of it we now have to version of the same package with the > identical version. > That situation did happened only couple of times over three years using > store, but still is there any automated way to prevent this from > happening again ? > > It look s like the "version" is just a varChar field on the package > table , so I was thinking about putting a unique constraint on it, but > then it will fail on the commit and I have to handle the commit failure . > > Any Ideas anyone ? > > Truly, > > --Mark Pirogovsky -- Charles A. Monteiro |
Re: Two store questions
|
|
In reply to this post by Mark Pirogovsky-3
oh yeah as to the second question perhaps if you override:
#isSaveableWithWarning or perhaps #validateOkayToPublish you can put in a check there to check the version string of the latest version of the package in question. BTW, why is it that I think that the system does do this somewhere, sometime? Anyhow, these seem to be the appropriate spots to put in checks before publishing. hth, -Charles On Thu, 23 Feb 2006 12:03:27 -0500, Mark Pirogovsky <[hidden email]> wrote: > Good morning everybody, > > I have two questions: > > 1. Is there a way or tool to find out the package/bundle prerequisites > before actually loading it ? > > 2. Recently me and my colleague were working on the same package, and > we did published the same package within a minutes from each other. The > end result of it we now have to version of the same package with the > identical version. > That situation did happened only couple of times over three years using > store, but still is there any automated way to prevent this from > happening again ? > > It look s like the "version" is just a varChar field on the package > table , so I was thinking about putting a unique constraint on it, but > then it will fail on the commit and I have to handle the commit failure . > > Any Ideas anyone ? > > Truly, > > --Mark Pirogovsky -- Charles A. Monteiro |
|
|
In reply to this post by Charles A. Monteiro-2
That is not very professional to reply to your own questions, sorry...
For everybody's benefit here is good answer for #1: In the "Published Items" window select a Pundle, then in the <Examine> menu select <List versions>, and then in the "Pundle version browser" window select a version and select <Properties> from the popUp menu-- it gives nice Properties tool, where you can see everything post load, pre load, prereq, etc. For the life of me I don't understand why it should be buried so deep in the tools :-( --Mark Charles A. Monteiro wrote: > Mark: > > For example: > (Store.Package allVersionsWithName: 'MyPackage') first > developmentPrerequisites > > > there may be a more direct way but I did verified that in a basically > virgin image i.e. MyPackage was not loaded , that it did provide me > with the pre-reqs. > > hth, > > -Charles > > > On Thu, 23 Feb 2006 12:03:27 -0500, Mark Pirogovsky > <[hidden email]> wrote: > > > self developmentPrerequisites > >> Good morning everybody, >> >> I have two questions: >> >> 1. Is there a way or tool to find out the package/bundle >> prerequisites before actually loading it ? >> >> 2. Recently me and my colleague were working on the same package, >> and we did published the same package within a minutes from each >> other. The end result of it we now have to version of the same >> package with the identical version. >> That situation did happened only couple of times over three years >> using store, but still is there any automated way to prevent this >> from happening again ? >> >> It look s like the "version" is just a varChar field on the package >> table , so I was thinking about putting a unique constraint on it, >> but then it will fail on the commit and I have to handle the commit >> failure . >> >> Any Ideas anyone ? >> >> Truly, >> >> --Mark Pirogovsky > > > > |
|
|
In reply to this post by Mark Pirogovsky-3
Mark,
When you publish something, the version string contains two parts separated by a comma. The second part is the user login name. This helps distinquish otherwise identical versions. Do you see this on the two versions of the package where the collision occurred? Charlie ----- Original Message ----- From: "Mark Pirogovsky" <[hidden email]> To: <[hidden email]> Sent: Thursday, February 23, 2006 11:03 AM Subject: Two store questions > Good morning everybody, > > I have two questions: > > 1. Is there a way or tool to find out the package/bundle prerequisites > before actually loading it ? > > 2. Recently me and my colleague were working on the same package, and we > did published the same package within a minutes from each other. The end > result of it we now have to version of the same package with the identical > version. > That situation did happened only couple of times over three years using > store, but still is there any automated way to prevent this from happening > again ? > > It look s like the "version" is just a varChar field on the package table > , so I was thinking about putting a unique constraint on it, but then it > will fail on the commit and I have to handle the commit failure . > > Any Ideas anyone ? > > Truly, > > --Mark Pirogovsky > > |
Re: Two store questions
|
|
In reply to this post by Mark Pirogovsky-3
Mark:
I assumed you wanted a programmatic way of ascertaining this i.e. so that you could put in convenience code i.e. for example in the Package publishing process. -Charles On Thu, 23 Feb 2006 13:04:10 -0500, Mark Pirogovsky <[hidden email]> wrote: > That is not very professional to reply to your own questions, sorry... > > > For everybody's benefit here is good answer for #1: > In the "Published Items" window select a Pundle, then in the <Examine> > menu select <List versions>, and then in the "Pundle version browser" > window select a version and select <Properties> from the popUp menu-- it > gives nice Properties tool, where you can see everything post load, pre > load, prereq, etc. > > For the life of me I don't understand why it should be buried so deep in > the tools :-( > > --Mark > > > Charles A. Monteiro wrote: > >> Mark: >> For example: >> (Store.Package allVersionsWithName: 'MyPackage') first >> developmentPrerequisites >> there may be a more direct way but I did verified that in a >> basically virgin image i.e. MyPackage was not loaded , that it did >> provide me with the pre-reqs. >> hth, >> -Charles >> On Thu, 23 Feb 2006 12:03:27 -0500, Mark Pirogovsky >> <[hidden email]> wrote: >> self developmentPrerequisites >> >>> Good morning everybody, >>> >>> I have two questions: >>> >>> 1. Is there a way or tool to find out the package/bundle >>> prerequisites before actually loading it ? >>> >>> 2. Recently me and my colleague were working on the same package, >>> and we did published the same package within a minutes from each >>> other. The end result of it we now have to version of the same >>> package with the identical version. >>> That situation did happened only couple of times over three years >>> using store, but still is there any automated way to prevent this >>> from happening again ? >>> >>> It look s like the "version" is just a varChar field on the package >>> table , so I was thinking about putting a unique constraint on it, >>> but then it will fail on the commit and I have to handle the commit >>> failure . >>> >>> Any Ideas anyone ? >>> >>> Truly, >>> >>> --Mark Pirogovsky >> -- Charles A. Monteiro |
|
|
In reply to this post by Mark Pirogovsky-3
Mark Pirogovsky wrote:
> That is not very professional to reply to your own questions, sorry... > > > For everybody's benefit here is good answer for #1: > In the "Published Items" window select a Pundle, then in the <Examine> > menu select <List versions>, and then in the "Pundle version browser" > window select a version and select <Properties> from the popUp menu-- it > gives nice Properties tool, where you can see everything post load, pre > load, prereq, etc. > > For the life of me I don't understand why it should be buried so deep in > the tools :-( > > --Mark Hmm. That seems to me like a fairly obvious place. * The Published Items window is the main tool for looking at things that aren't loaded. * Prerequisites can vary for each published version, so you have to be looking at a particular version to know its prerequisites. * "Properties" seems reasonable as a way to find information that isn't already shown, and is the same label you go to in the RB to see prerequisites in loaded pundles. It would be nice, though, to have a more unified interface to this information, perhaps a browser GUI that lets you browse through the repository by pundle, version, definitions, properties, etc. all in the same window, just like the RB lets you browse through the loaded pundles all in one window. Regards, -Martin |
|
|
Martin,
In the "Published items" UI we already have a list of versions. To get to the properties you have to go to the menu bar, from there open another UI, and then on the same version list(you already had), use the popUp menu to open yet another UI for properties. For now I just did modify the menu for the "Published item" version list so I can get to the properties from there. Now it is logical - when I see a list I want to be able to see item's property without circumlocutions. --Mark Martin McClure wrote: > Mark Pirogovsky wrote: > >> That is not very professional to reply to your own questions, sorry... >> >> >> For everybody's benefit here is good answer for #1: >> In the "Published Items" window select a Pundle, then in the <Examine> >> menu select <List versions>, and then in the "Pundle version browser" >> window select a version and select <Properties> from the popUp menu-- >> it gives nice Properties tool, where you can see everything post load, >> pre load, prereq, etc. >> >> For the life of me I don't understand why it should be buried so deep >> in the tools :-( >> >> --Mark > > > Hmm. That seems to me like a fairly obvious place. > > * The Published Items window is the main tool for looking at things that > aren't loaded. > > * Prerequisites can vary for each published version, so you have to be > looking at a particular version to know its prerequisites. > > * "Properties" seems reasonable as a way to find information that isn't > already shown, and is the same label you go to in the RB to see > prerequisites in loaded pundles. > > > It would be nice, though, to have a more unified interface to this > information, perhaps a browser GUI that lets you browse through the > repository by pundle, version, definitions, properties, etc. all in the > same window, just like the RB lets you browse through the loaded pundles > all in one window. > > Regards, > > -Martin > > > |
|
|
Mark Pirogovsky wrote:
> Martin, > In the "Published items" UI we already have a list of versions. To get > to the properties you have to go to the menu bar, from there open > another UI, and then on the same version list(you already had), use the > popUp menu to open yet another UI for properties. > > For now I just did modify the menu for the "Published item" version list > so I can get to the properties from there. Now it is logical - when I > see a list I want to be able to see item's property without > circumlocutions. Mark, You are, of course, right -- I should have taken a closer look before commenting. Having the menu of the Versions pane of the Published Items window be different from the menu of the versions pane of the Database Version Browser, and even omit key menu items, is unnecessarily confusing. Thanks for clarifying. Regards, -Martin > > Martin McClure wrote: > >> Mark Pirogovsky wrote: >> >>> That is not very professional to reply to your own questions, sorry... >>> >>> >>> For everybody's benefit here is good answer for #1: >>> In the "Published Items" window select a Pundle, then in the >>> <Examine> menu select <List versions>, and then in the "Pundle >>> version browser" window select a version and select <Properties> from >>> the popUp menu-- it gives nice Properties tool, where you can see >>> everything post load, pre load, prereq, etc. >>> >>> For the life of me I don't understand why it should be buried so deep >>> in the tools :-( >>> >>> --Mark >> >> >> Hmm. That seems to me like a fairly obvious place. >> >> * The Published Items window is the main tool for looking at things >> that aren't loaded. >> >> * Prerequisites can vary for each published version, so you have to be >> looking at a particular version to know its prerequisites. >> >> * "Properties" seems reasonable as a way to find information that >> isn't already shown, and is the same label you go to in the RB to see >> prerequisites in loaded pundles. >> >> >> It would be nice, though, to have a more unified interface to this >> information, perhaps a browser GUI that lets you browse through the >> repository by pundle, version, definitions, properties, etc. all in >> the same window, just like the RB lets you browse through the loaded >> pundles all in one window. >> >> Regards, >> >> -Martin >> >> >> |
[Pollock]Setting font for TextEdit control
|
|
I'd really like to set the font on a Pollock TextEdit to courier or
some other monospaced terminal font. I'm used to VisualSmalltalk where this is really easy to do, but I couldn't figure out how this works in VW and Pollock. Anyone have a quick pointer? Thanks! -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Re: [Pollock]Setting font for TextEdit control
|
|
Welcome to VisualWorks fonts where this is -not- easy to do.
What I'd like is a simple font/font: interface where I can simply give the various widgets a font I want them to use. Unfortunately, this apparently isn't possible in Pollock right now. The reason is, Pollock uses the various Scanner classes that come with Wrappers to do vertical text orientation, horizontal spacing and even wrapping. These scanners are hard coded to use the TextAttribute classes. These classes are an abomination until mankind. But, basically, what you need to do is make yourself a TextAttribute instance and you can give -that- to the TextEdit. Needless to say, WithStyle does -not- do this. Nor does WithStyle use those horrible Scanners. Sam has promised that in the next one or two projects this area will be completely rewritten so we can just give the widget the desired font. *fingers crossed* </end rant> Cheers, Michael > I'd really like to set the font on a Pollock TextEdit to courier or > some other monospaced terminal font. I'm used to VisualSmalltalk where > this is really easy to do, but I couldn't figure out how this works in > VW and Pollock. Anyone have a quick pointer? > Thanks! > -Carl Gundel, author of Liberty BASIC > http://www.libertybasic.com |
Re: [Pollock]Setting font for TextEdit control
|
|
On Feb 23, 2006, at 6:42 PM, Michael Lucas-Smith wrote:
> These scanners are hard coded to use the TextAttribute classes. These > classes are an abomination until mankind. But, basically, what you > need to do is make yourself a TextAttribute instance and you can give > -that- to the TextEdit. Okay. :-) How do I do that? Do you have a code snippet that shows how? > Needless to say, WithStyle does -not- do this. Nor does WithStyle use > those horrible Scanners. > > Sam has promised that in the next one or two projects this area will > be completely rewritten so we can just give the widget the desired > font. *fingers crossed* It sure would be great to be able to code something like: aTextEdit setFont: (Font faceName: 'courier new' size: 10 bold: false italic: false) -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Re[2]: [Pollock]Setting font for TextEdit control
|
|
<end rant>
Yeah it's not as hard as I make it sound, but beware - do not try to copy an existing TextAttributes and modify it.. the copy doesn't work and you end up changing our environment :) Example from TextAttributes>>initializeDefault cStyle := VariableCharacterAttributes newWithDefaultAttributes. cStyle setDefaultQuery: (FontDescription new family: #('helv' 'helvetica' 'arial' '*'); manufacturer: #('adobe' '*'); fixedWidth: false; serif: false; italic: false; boldness: 0.5; pixelSize: 12). cStyle noScaling. style := self new. style setCharacterAttributes: cStyle. > On Feb 23, 2006, at 6:42 PM, Michael Lucas-Smith wrote: >> These scanners are hard coded to use the TextAttribute classes. These >> classes are an abomination until mankind. But, basically, what you >> need to do is make yourself a TextAttribute instance and you can give >> -that- to the TextEdit. > Okay. :-) How do I do that? Do you have a code snippet that shows > how? >> Needless to say, WithStyle does -not- do this. Nor does WithStyle use >> those horrible Scanners. >> >> Sam has promised that in the next one or two projects this area will >> be completely rewritten so we can just give the widget the desired >> font. *fingers crossed* > It sure would be great to be able to code something like: > aTextEdit setFont: > (Font > faceName: 'courier new' > size: 10 > bold: false > italic: false) > -Carl Gundel, author of Liberty BASIC > http://www.libertybasic.com |
Re: Two store questions
|
|
In reply to this post by Martin McClure
it should be in the very same RB browser except that unloaded pundles
would have different icons/emphasis etc. The settings for RB could provide the option to see unloaded packages and since we are sort of on the subject I would love to have a filter/exclusion list on what pundles I see in th e RB browser by default. -Charles On Thu, 23 Feb 2006 17:23:33 -0500, Martin McClure <[hidden email]> wrote: > Mark Pirogovsky wrote: >> That is not very professional to reply to your own questions, sorry... >> For everybody's benefit here is good answer for #1: >> In the "Published Items" window select a Pundle, then in the <Examine> >> menu select <List versions>, and then in the "Pundle version browser" >> window select a version and select <Properties> from the popUp menu-- >> it gives nice Properties tool, where you can see everything post load, >> pre load, prereq, etc. >> For the life of me I don't understand why it should be buried so deep >> in the tools :-( >> --Mark > > Hmm. That seems to me like a fairly obvious place. > > * The Published Items window is the main tool for looking at things that > aren't loaded. > > * Prerequisites can vary for each published version, so you have to be > looking at a particular version to know its prerequisites. > > * "Properties" seems reasonable as a way to find information that isn't > already shown, and is the same label you go to in the RB to see > prerequisites in loaded pundles. > > > It would be nice, though, to have a more unified interface to this > information, perhaps a browser GUI that lets you browse through the > repository by pundle, version, definitions, properties, etc. all in the > same window, just like the RB lets you browse through the loaded pundles > all in one window. > > Regards, > > -Martin -- Charles A. Monteiro |
|
|
In reply to this post by Mark Pirogovsky-3
Was your second question ever answered? I'm curious how it was resolved.
There seems to be a timing hole in the publication mechanism. I'd like to know it was addressed. ----- Original Message ----- From: "Mark Pirogovsky" <[hidden email]> To: <[hidden email]> Sent: Thursday, February 23, 2006 11:03 AM Subject: Two store questions > Good morning everybody, > > I have two questions: > > 1. Is there a way or tool to find out the package/bundle prerequisites > before actually loading it ? > > 2. Recently me and my colleague were working on the same package, and we > did published the same package within a minutes from each other. The end > result of it we now have to version of the same package with the identical > version. > That situation did happened only couple of times over three years using > store, but still is there any automated way to prevent this from happening > again ? > > It look s like the "version" is just a varChar field on the package table > , so I was thinking about putting a unique constraint on it, but then it > will fail on the commit and I have to handle the commit failure . > > Any Ideas anyone ? > > Truly, > > --Mark Pirogovsky > > |
|
|
Charlie Adams wrote:
> Was your second question ever answered? I'm curious how it was resolved. > There seems to be a timing hole in the publication mechanism. I'd like > to know it was addressed. You can use your cluestick in two ways: either beat Cincom over the head with it or use it as a physical commit token in your organization. (In all truth I can think of more uses, doorstop comes to mind...) /me ducks Reinout ------- |
|
|
In reply to this post by Charles Adams
I'd say he answered it himself. There is clearly a timing hole, because publishing is transactional. The only way you could avoid that would be to have the database fail the second commit, e.g. by having a unique constraint on the name + version name. Putting a unique constraint on just version name would probably mean that, e.g. only one package could be versioned as 1.0. And the second person publishing would basically just get a database failure error. You could wrap that up more nicely, but they're still going to have to go back and pick new version numbers.
At 09:51 AM 2/24/2006, Charlie Adams wrote: >Was your second question ever answered? I'm curious how it was resolved. There seems to be a timing hole in the publication mechanism. I'd like to know it was addressed. > >----- Original Message ----- From: "Mark Pirogovsky" <[hidden email]> >To: <[hidden email]> >Sent: Thursday, February 23, 2006 11:03 AM >Subject: Two store questions > > >>Good morning everybody, >> >>I have two questions: >> >>1. Is there a way or tool to find out the package/bundle prerequisites before actually loading it ? >> >>2. Recently me and my colleague were working on the same package, and we did published the same package within a minutes from each other. The end result of it we now have to version of the same package with the identical version. >>That situation did happened only couple of times over three years using store, but still is there any automated way to prevent this from happening again ? >> >>It look s like the "version" is just a varChar field on the package table , so I was thinking about putting a unique constraint on it, but then it will fail on the commit and I have to handle the commit failure . >> >>Any Ideas anyone ? >> >>Truly, >> >>--Mark Pirogovsky >> -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
|
|
Alan Knight wrote:
> I'd say he answered it himself. There is clearly a timing hole, because > publishing is transactional. The only way you could avoid that would be to > have the database fail the second commit, e.g. by having a unique > constraint on the name + version name. [...] > You could wrap that up more nicely, but they're > still going to have to go back and pick new version numbers. Fail-fast seems wise in this case, I prefer such a solution over letting code corruption happen silently. Will Cincom put this on their to-do list? R - |
|
|
In reply to this post by Reinout Heeck
Reinout Heeck wrote:
> Charlie Adams wrote: > >> Was your second question ever answered? I'm curious how it was >> resolved. There seems to be a timing hole in the publication >> mechanism. I'd like to know it was addressed. > > > > You can use your cluestick in two ways: > > either beat Cincom over the head with it > or use it as a physical commit token in your organization. > > (In all truth I can think of more uses, doorstop comes to mind...) > > > > /me ducks > > Reinout > ------- Reinout, what was the purpose of your response? Chris |
|
|
In reply to this post by Alan Knight-2
Is there no gating process to these transactions? I apologize for my
complete cluelessness over database transactions in Store. With some gating process, it would seem to me to be a simply thing to close this hole. Without one, yeah, this sounds hairy. Perhaps that's the problem. For what it's worth, attempts to publish a duplicate versions already fail. Silently. Most of the time. Except when they don't. It takes tight timing to make them succeed. ----- Original Message ----- From: "Alan Knight" <[hidden email]> To: "Charlie Adams" <[hidden email]>; <[hidden email]> Sent: Friday, February 24, 2006 10:43 AM Subject: Re: Two store questions > I'd say he answered it himself. There is clearly a timing hole, because > publishing is transactional. The only way you could avoid that would be to > have the database fail the second commit, e.g. by having a unique > constraint on the name + version name. Putting a unique constraint on just > version name would probably mean that, e.g. only one package could be > versioned as 1.0. And the second person publishing would basically just > get a database failure error. You could wrap that up more nicely, but > they're still going to have to go back and pick new version numbers. > > At 09:51 AM 2/24/2006, Charlie Adams wrote: >>Was your second question ever answered? I'm curious how it was resolved. >>There seems to be a timing hole in the publication mechanism. I'd like to >>know it was addressed. >> >>----- Original Message ----- From: "Mark Pirogovsky" >><[hidden email]> >>To: <[hidden email]> >>Sent: Thursday, February 23, 2006 11:03 AM >>Subject: Two store questions >> >> >>>Good morning everybody, >>> >>>I have two questions: >>> >>>1. Is there a way or tool to find out the package/bundle prerequisites >>>before actually loading it ? >>> >>>2. Recently me and my colleague were working on the same package, and we >>>did published the same package within a minutes from each other. The end >>>result of it we now have to version of the same package with the >>>identical version. >>>That situation did happened only couple of times over three years using >>>store, but still is there any automated way to prevent this from >>>happening again ? >>> >>>It look s like the "version" is just a varChar field on the package table >>>, so I was thinking about putting a unique constraint on it, but then it >>>will fail on the commit and I have to handle the commit failure . >>> >>>Any Ideas anyone ? >>> >>>Truly, >>> >>>--Mark Pirogovsky >>> > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > > "The Static Typing Philosophy: Make it fast. Make it right. Make it > run." - Niall Ross > > |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |