Activity
From 03/03/2013 to 04/01/2013
04/01/2013
- 11:22 AM Feature #1920: implement persistent procedures
- Note 80 from #2080 shows a missing error for function invocation:...
- 10:53 AM Feature #1613: finish FILE-INFO system handle support
- Added proposed update, with the modified search function, eliminated the change in EnvironmentOps since it wasn't nec...
- 09:29 AM Feature #1613: finish FILE-INFO system handle support
- > In the Javadoc of EnvironmentOps.searchPath() there is this saying:
I think you mean EnvironmentOps.getSearchPat...
03/29/2013
- 07:06 PM Feature #1650: process launching support for Windows (JNI library changes and any associated modi...
- This is update just for review to see the approach. It compiles native DLL in Windows 32-bit using mingw32-gcc. Plann...
- 01:41 PM Feature #1584: add conversion and runtime support for INT64 and DATETIME data types
- This update adds implementation for all TODOs from @int64@ and, since the implementation is mostly the same for the @...
- 09:19 AM Bug #2105: BlockManager does not return some datatypes correctly
- A first attempt to fix would be to have only one @returnNormal@ static function with a BDT parameter and the value wr...
- 09:04 AM Bug #2105: BlockManager does not return some datatypes correctly
- Consider the following 4GL code:...
- 08:55 AM Bug #2105 (New): BlockManager does not return some datatypes correctly
03/28/2013
- 01:26 PM Feature #1613: finish FILE-INFO system handle support
- I retested the cases from UAST which contained search function or Propath and there weren't any difference,
However ... - 08:53 AM Feature #1613: finish FILE-INFO system handle support
- In the Javadoc of EnvironmentOps.searchPath() there is this saying:...
- 08:48 AM Feature #1613: finish FILE-INFO system handle support
- I don't understand why the comma is included in the default path. We already have protection against the path being ...
- 08:37 AM Feature #1650: process launching support for Windows (JNI library changes and any associated modi...
- You are allowed to use Windows in KVM on the same Ubuntu system. It will be allowed in the standards. Thanks for as...
03/27/2013
- 04:21 PM Feature #1650: process launching support for Windows (JNI library changes and any associated modi...
- The question. I have idea to install The Windows inside the KVM Virtual Machine on my new Ubuntu box. Will it also co...
- 02:58 PM Feature #1613: finish FILE-INFO system handle support
- There seems to be an error in the search() logic of FileSystemDaemon.
If the given paths Array is non null it will s...
03/26/2013
- 11:13 AM Feature #1613: finish FILE-INFO system handle support
- Code Feedback:
1. StreamWrapper has no real changes other than the copyright date and the history entry. Does it ...
03/25/2013
- 04:14 PM Feature #1626: implement OS-DIR support as an INPUT stream
- Added proposed update.The update is for both #1613 and #1626
- 04:13 PM Feature #1613: finish FILE-INFO system handle support
- Added proposed update.The update is for both #1613 and #1626
- 08:40 AM Feature #1584: add conversion and runtime support for INT64 and DATETIME data types
- Ovidiu: your next priority should be completing the runtime work on this task. The first priority is to get the int6...
03/23/2013
- 03:18 PM Bug #2070: BlockManager Action disambiguation
- Converting the extent_params_proc.p test on windows fails with this:...
03/22/2013
- 09:37 AM Feature #1920: implement persistent procedures
- Merged with latest bzr version, contains both CA 0322a.zip and CA 0322f.zip changes. committed to bzr revision 10313.
- 08:24 AM Feature #1920: implement persistent procedures
- The code is OK. It can be committed and distributed when it passes testing.
- 07:54 AM Feature #1920: implement persistent procedures
- Fixes the case when a method param has subscript:...
- 06:04 AM Feature #1920: implement persistent procedures
- The code is OK. If it passes conversion testing you can check it in and distribute it.
- 05:31 AM Feature #1920: implement persistent procedures
- Fixed conversion support for HANDLE attribute, when used with system handles:...
- 06:59 AM Feature #1608: implement full appserver support (from 4GL clients only)
- Checked in to bzr as revision 10310.
- 05:26 AM Feature #1608: implement full appserver support (from 4GL clients only)
- Conversion testing passed. Check it in and distribute it.
03/21/2013
- 04:10 PM Feature #1608: implement full appserver support (from 4GL clients only)
- Added merged update
- 01:51 PM Feature #1608: implement full appserver support (from 4GL clients only)
- Code Feedback:
1. The javadoc and formatting of ConnectableServer should be this:... - 01:13 PM Feature #1608: implement full appserver support (from 4GL clients only)
- Added proposed update which fixes connect for AppServer
- 10:37 AM Feature #1608: implement full appserver support (from 4GL clients only)
- You can force things to be wrapped in that case where there is more than 1 parameter.
- 10:27 AM Feature #1608: implement full appserver support (from 4GL clients only)
- > [javac] .../server/common/Apitest1.java:134: error: no suitable method found for connect(String,character,character...
- 01:32 PM Bug #2099 (Closed): "ASSIGN widget." statement does not convert properly in some cases
- 12:53 PM Bug #2099 (Review): "ASSIGN widget." statement does not convert properly in some cases
- > Check it in and distribute it.
Committed to bzr revision 10308. - 12:46 PM Bug #2099: "ASSIGN widget." statement does not convert properly in some cases
- This looks good. Check it in and distribute it.
- 11:41 AM Bug #2099: "ASSIGN widget." statement does not convert properly in some cases
- This update has passed conversion regression testing. There are some changes in MAJIC, but they do not affect runtime...
- 09:45 AM Bug #2099: "ASSIGN widget." statement does not convert properly in some cases
- I'm still missing something, lots of invalid changes in MAJIC.
- 08:58 AM Bug #2099: "ASSIGN widget." statement does not convert properly in some cases
- This is a fix attempt for this issue. Looks like the solution was to explicitly set the frame name, in case the "fram...
- 11:23 AM Feature #2089 (Closed): INPUT function returning string value
- 10:37 AM Feature #2089: INPUT function returning string value
- Please do check in and distribute the change.
- 10:14 AM Feature #2089: INPUT function returning string value
- Yes, they all are OK.
- 09:51 AM Feature #2089: INPUT function returning string value
- Here are the results of the conversion testing:...
- 08:12 AM Feature #2089: INPUT function returning string value
- Code Review:
It looks good. 1 minor issue: the comment was corrupted in "handle_implicit_input" in the latest com...
03/20/2013
- 05:54 PM Feature #1641: implement SAX XML support
- The update evl_upd20130320b.zip has been committed in bzr as 10303.
- 05:46 PM Feature #1641: implement SAX XML support
- > If it passes testing you can check it in and distribute it.
Conversion testing has been passed. I'm going to com... - 04:40 PM Feature #1641: implement SAX XML support
- If it passes testing you can check it in and distribute it.
- 03:11 PM Feature #1641: implement SAX XML support
- This update merged with bzr 10302. Starting the conversion testing.
- 02:46 PM Feature #1641: implement SAX XML support
- Code feedback: everything looks good.
The only issue is that you need to merge with the recent bzr revision. Ple... - 02:36 PM Feature #1641: implement SAX XML support
- The update includes:
1. Changing for constant types.
2. Adding history entries.
3. Fixes for misspelled words in S... - 02:16 PM Feature #2089: INPUT function returning string value
- Yes, please do.
- 02:13 PM Feature #2089: INPUT function returning string value
- > When we search upward for KW_VALIDATE and enable implicit input testing, we must ensure that we are a descendant of...
- 02:00 PM Feature #2089: INPUT function returning string value
- When we search upward for KW_VALIDATE and enable implicit input testing, we must ensure that we are a descendant of t...
- 01:49 PM Feature #2089: INPUT function returning string value
- Note that...
- 12:26 PM Bug #2099: "ASSIGN widget." statement does not convert properly in some cases
- This case was exposed by server folder compilation, in #2068 note 172:...
- 12:08 PM Bug #2099 (Closed): "ASSIGN widget." statement does not convert properly in some cases
03/19/2013
- 07:46 PM Feature #2089: INPUT function returning string value
- 1 compile problem in Majic:...
- 03:13 PM Feature #2089: INPUT function returning string value
- The code looks good. I will put it into conversion testing here since it will be faster.
- 02:58 PM Feature #2089: INPUT function returning string value
- Not yet regression-tested.
- 09:42 AM Feature #2089: INPUT function returning string value
- > Stanislav: when will the update be ready?
I'm writing javadocs / merging it. - 09:17 AM Feature #2089: INPUT function returning string value
- Actually, this should be pretty much done at this point. Let's finish it now.
Stanislav: when will the update be ... - 07:51 AM Feature #2089: INPUT function returning string value
- Greg/Stanislav: we can make this a low priority, as after the latest schema VALEXP changes in #1620, the problematic ...
- 11:41 AM Feature #1641: implement SAX XML support
- > AFAIK any field declared in an interface is by default "static final" (the compiler takes care to put these modifie...
- 11:08 AM Feature #1641: implement SAX XML support
- > 1. Please make the constants all @public final static@ instead of just @public@ (which is editable, something we do...
- 09:45 AM Feature #1641: implement SAX XML support
- Code Feedback (Eugenie: you can make the final changes to the code Constantin posted):
1. Please make the constant... - 08:18 AM Feature #1641: implement SAX XML support
- Eugenie: attached you have the runtime support for this; please go ahead with the conversion support.
Greg: the co... - 08:13 AM Feature #1641: implement SAX XML support
- Eugenie, please implement the following:
These constants are recognized by the parser but we do not emit them as l... - 07:03 AM Feature #1620: implement EXTENT parameter support
- Attached merged update, committed to bzr revision 10298.
- 07:02 AM Feature #1620: implement EXTENT parameter support
- > If it passes conversion testing AND if you deem the Majic changes to be correct, then go ahead and check in/distrib...
03/18/2013
- 05:35 PM Feature #2089: INPUT function returning string value
- Understood.
- 05:27 PM Feature #2089: INPUT function returning string value
- > Also: this fuzzy matching may have bad side effects on other places we use expressionType(). For this reason, I th...
- 03:36 PM Feature #2089: INPUT function returning string value
- Yes, that is my point. getSignature(int, int, String[]) should be modified to return the default as the first one de...
- 03:13 PM Feature #2089: INPUT function returning string value
- > In regard to your idea about a default signature, I am OK with that approach. How about this: if the signature mat...
- 03:07 PM Feature #2089: INPUT function returning string value
- Greg Shah wrote:
> OK, you have to some some additional things here.
>
> 1. Before you set the implicit_input, yo... - 02:59 PM Feature #2089: INPUT function returning string value
- OK, you have to some some additional things here.
1. Before you set the implicit_input, you must first know the de... - 02:14 PM Feature #2089: INPUT function returning string value
- > Please post the code you are using to implement the implicit_input analysis....
- 01:50 PM Feature #2089: INPUT function returning string value
- In regard to your idea about a default signature, I am OK with that approach. How about this: if the signature match...
- 01:34 PM Feature #2089: INPUT function returning string value
- Please post the code you are using to implement the implicit_input analysis.
- 01:16 PM Feature #2089: INPUT function returning string value
- > What is the problem with the use of ParmType.BDT (BaseDataType) as the 1st parameter (the way it was originally cod...
- 12:19 PM Feature #2089: INPUT function returning string value
- What is the problem with the use of ParmType.BDT (BaseDataType) as the 1st parameter (the way it was originally coded)?
- 11:25 AM Feature #2089: INPUT function returning string value
- Signature of the @LENGTH@ function stored into @SignatureHelper.map_func@ map is @{ ParmType.BDT, ParmType.CHAR }@. A...
- 12:30 PM Feature #1620: implement EXTENT parameter support
- This makes sense. I should have read the surrounding code more carefully and I would have seen this.
If it passes... - 11:58 AM Feature #1620: implement EXTENT parameter support
- > My only question is this: the schema_validation.rules includes support for the INSERT statement, but then the FORMA...
- 11:52 AM Feature #1620: implement EXTENT parameter support
- Code Review:
My only question is this: the schema_validation.rules includes support for the INSERT statement, but ... - 10:42 AM Feature #1620: implement EXTENT parameter support
- New version of the update in which:
# the NO-VALIDATE clause with a frame must affect only the schema validation exp...
03/17/2013
- 04:34 PM Feature #1620: implement EXTENT parameter support
- I'm OK with the changes. If all of the Majic modifications appear to be correct, we will go ahead with runtime testin...
- 11:16 AM Feature #1620: implement EXTENT parameter support
- There are lots of changes in MAJIC converted code, here are some examples:
# for extent fields, all elements get the... - 10:03 AM Feature #1620: implement EXTENT parameter support
- Renamed test file.
- 10:01 AM Feature #1620: implement EXTENT parameter support
- When fixing conversion of schema validation expressions for extent fields, it hit me that the P2J approach using SCHE...
03/14/2013
- 05:07 PM Feature #2089: INPUT function returning string value
- ...
- 09:55 PM Feature #2089: INPUT function returning string value
- I have an update posted in #2053. It is in testing, but hopefully you can use it to test your changes.
- 12:04 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Committed to bzr revision 10285.
- 10:27 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- The update looks good. You can check it in and distribute it.
- 09:56 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Correct, good letter, wrong date. Attached is the good one.
- 08:13 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- I think the wrong update is posted here.
03/13/2013
- 06:14 PM Feature #2089: INPUT function returning string value
- About note 8: no.
You can do the following:
1. Determine the type (wrapper classname: like "integer") of the va... - 06:00 PM Feature #2089: INPUT function returning string value
- Yes, you should work on item 2 and my changes will enable item 1. Please note that I don't want to transform all val...
- 04:42 PM Feature #2089: INPUT function returning string value
- In regards to #2: should I parent all occurrences of a validated value with FUNC_POLY node as a solution?
- 02:12 PM Feature #2089: INPUT function returning string value
- OK, I missed that. So your question remains.
- 02:11 PM Feature #2089: INPUT function returning string value
- Greg was saying that "I am currently working to extend that facility to be more robust, including detecting the case ...
- 01:53 PM Feature #2089: INPUT function returning string value
- Stanislav Lomany wrote:
> So, am I correct that except checking the runtime part we have two problems:
> 1. It is n... - 01:47 PM Feature #2089: INPUT function returning string value
- So, am I correct that except checking the runtime part we have two problems:
1. It is not properly recognized that a... - 03:15 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- The update has passed conversion regression testing.
- 02:33 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- The only remaining problem was with char field initializers, which were not handled (it was parsers fault). The notes...
03/12/2013
- 04:05 PM Feature #2089: INPUT function returning string value
- As Constantin notes, the INPUT function in the 4GL can return either the actual data type of the widget OR it can ret...
- 03:46 PM Feature #2089: INPUT function returning string value
- Greg, how should correctly converted validation code look like for the following example?...
- 03:12 PM Feature #2089: INPUT function returning string value
- Copied from #2068:
*CA*
Another problem found in at least rtb/ folder:... - 03:09 PM Feature #2089 (Closed): INPUT function returning string value
03/11/2013
- 11:09 AM Feature #1640: implement DOM XML support
- Added more missing APIs. Committed to bzr revision 10276
- 11:05 AM Feature #1884: add some of the v10 data types and core built-ins
- -Added more missing APIs. Committed to bzr revision 10276- was for task #1640
03/09/2013
- 03:57 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- A simple change to ECW fixes this. I am making some other changes to the ECW as well. Then I will conversion test t...
- 11:25 AM Bug #2076: DMO setter fails when parameter is BaseDataType
- There is a regression related to this update:...
- 03:56 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- Yes, I'm thinking about what is the right solution here. I wonder if I should make the previous solution (the extra ...
- 03:52 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- Hmm... on a second thought, this is similar to the DMO setter case... it should wrap the _POLY/DB_NON_REF in a logica...
- 03:34 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- I'm not sure the problem is in the ECW. Actually, there is never any attempt to call the ECW for these cases. If I ...
- 11:13 AM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- The strange thing is that I already put in support for all of these cases. I guess it is not working properly. I wi...
- 07:28 AM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- The ExpressionConversion worker needs to treat the cases when a _POLY is used in a logical test, as in:...
- 11:11 AM Feature #2087 (Closed): add support for extent vars/fields used with a PUT statement (stream-only...
- Checked in as bzr revision 10273.
- 04:44 AM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- The ges_upd20130308g.zip update has passed conversion regression testing.
- 03:01 AM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- Thanks, that did the trick. I'm putting it through conversion regression testing.
- 11:06 AM Bug #2065 (Closed): ambiguity in date/decimal literals that is not handled properly by the Progre...
- 11:06 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Passed conversion testing and checked in as bzr revision 10272.
- 02:55 AM Feature #1640: implement DOM XML support
- Adds two missing APIs in XmlFactory, related to WIDGET-POOL clause. Committed to bzr revision 10271.
03/08/2013
- 05:25 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- Take a look at this. I think this should do the same thing.
- 03:59 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- The good news is that 0308h.zip has passed conversion regression testing - no changes.
- 03:47 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- I had a feeling there was another file where this was done already for some other cases, but my brain chose to ignore...
- 03:41 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- Code Review:
Could we have added this as an additional case in annotations/array_expansion.rules? - 02:58 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- Had a regression (didn't handle the case when the PUT used a subscripted field). Back in regression testing.
- 01:31 PM Feature #2087: add support for extent vars/fields used with a PUT statement (stream-only feature)
- 4GL allows extent vars/fields to be used in a PUT statement:...
- 01:27 PM Feature #2087 (Closed): add support for extent vars/fields used with a PUT statement (stream-only...
- 05:05 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Fix for empty string used as a date var initializer. It is being conversion tested now.
- 04:30 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Passed conversion testing and checked in as revision 10269.
I'll handle the date from an empty string next. - 03:38 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Another issue related to dates:...
- 03:28 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Final version going through conversion testing now. There was an issue with removal of zeros from the year portion o...
- 02:05 PM Bug #2065 (WIP): ambiguity in date/decimal literals that is not handled properly by the ProgressL...
- How many times am I going to be wrong today? Majic compiled fine with the c update but there are still many unwanted...
- 12:12 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Another silly mistake, I didn't properly exclude num literals from the trailing zero removal. This updated version i...
- 10:56 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Fixed a stupid indexing error. Going back into conversion testing.
- 10:48 AM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- Updated version of the testcase plus the prepared fixes which are going into conversion testing now.
The core solu... - 10:35 AM Feature #1640: implement DOM XML support
- Committed to bzr revision 10267
- 10:02 AM Feature #1640: implement DOM XML support
- I'm fine with the change. Commit and distribute it.
- 09:45 AM Feature #1640: implement DOM XML support
- ca_upd20130308d.zip has passed conversion regression testing.
- 08:15 AM Feature #1640: implement DOM XML support
- Fixed conversion of CREATE statements related to XML support. The correct approach is to pass the handle instance as ...
03/07/2013
- 05:00 PM Bug #2076 (Closed): DMO setter fails when parameter is BaseDataType
- 04:58 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Passes conversion testing and is checked into bzr as revision 10264.
- 04:46 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- No, that is alright. The difference is not significant at runtime. Thanks.
I will check this in and distribute it. - 04:41 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- > Constantin: what do you think?
The result will not affect runtime, is just some small overhead. I think this is be... - 04:32 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Conversion testing has finished. There is this one unexpected change:...
- 02:25 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- This update is fine. I will conversion regression test it.
> Sorry I missed the "rule" directory , what I do when... - 01:14 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Added proposed update.
Sorry I missed the "rule" directory , what I do when adding an update: I manually create the... - 12:20 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Code Feedback:
1. Your zip still has the wrong directory name "rule" instead of "rules". How is that even getting... - 06:06 AM Bug #2076: DMO setter fails when parameter is BaseDataType
- Added proposed update (uploaded it first by mistake to #2070)
- 12:42 PM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Greg Shah wrote:
> I'm not sure why you switched from a Set to a Map in fixups/variable_definitions.rules (did you p... - 12:29 PM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- I'm not sure why you switched from a Set to a Map in fixups/variable_definitions.rules (did you plan to use it and th...
- 12:13 PM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- The edited file is in task #2085.
This update has passed conversion regression testing (there are changes in two f... - 09:51 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- MAJIC has the case at note 14 in only one file. I've checked the history of this file and this change was introduced ...
- 08:59 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Fixed a problem (I was using varDict.getSymbol instead of varDict.getSymbolAtScope(name, 0) to search only in the cur...
- 08:45 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- This has regressions, one of them relaed to this, as 4GL (v9-only I think) allowed this:...
- 06:27 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- So the problem was that the parser was adding tempidx to the dupped vars too. The sollution was to not register the d...
- 05:49 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- I need to rewrite this at the parser side, as the duped var gets ref'ed by the parser:...
- 05:13 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Fixed multiple calls like:...
- 12:02 PM Bug #2069: Accumulator temp table field disambiguation
- Committed to bzr revision 10262.
- 11:56 AM Bug #2069: Accumulator temp table field disambiguation
- The change looks fine. Check it in and distribute it.
- 05:51 AM Bug #2069: Accumulator temp table field disambiguation
- This has passed conversion regression testing.
- 04:53 AM Bug #2069: Accumulator temp table field disambiguation
- I think the sollution was to mark the tables which are weak reference as preferred, when abbreviations are encountere...
- 03:51 AM Bug #2069: Accumulator temp table field disambiguation
- Another creature of the rabbit hole found at #1985, 120. This fails:...
- 05:28 AM Bug #2070: BlockManager Action disambiguation
- Added update to wrong task deleting it
03/06/2013
- 01:50 PM Feature #1884: add some of the v10 data types and core built-ins
- Committed to bzr revision 10259.
- 01:45 PM Feature #1884: add some of the v10 data types and core built-ins
- I agree. The code is fine. Check it in and distribute it.
- 01:30 PM Feature #1884: add some of the v10 data types and core built-ins
- Added missing TextOps.numEntries(String, String). I don't see a reason to put this through conversion regression test...
- 01:25 PM Bug #2065: ambiguity in date/decimal literals that is not handled properly by the ProgressLexer
- The following testcase shows the limits of this ambiguity.
From the header:... - 01:20 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- That crossed my mind too and started in that direction in the morning, but thought about the copy Ast with null paren...
- 01:09 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- The best thing to do here is to move the current logic for ECW.expressionType(Aast) to a new public worker method ECW...
- 12:44 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- The AST...
- 12:39 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Please post the AST here for the @assign test.int-field = h:BUFFER-FIELD("dsc"):BUFFER-VALUE(2).@.
- 12:16 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- I'll use this example to explain....
- 11:45 AM Bug #2076: DMO setter fails when parameter is BaseDataType
- Code Review:
> I first tried to use ExpresionConversionWorker.expressionType with an ast copy without a parent (be... - 11:24 AM Bug #2076: DMO setter fails when parameter is BaseDataType
- Added proposed update
NOTE
I first tried to use ExpresionConversionWorker.expressionType with an ast copy without... - 12:54 PM Feature #1920: implement persistent procedures
- Added merged update, which was committed to bzr revision 10258.
- 12:44 PM Feature #1920: implement persistent procedures
- Passed conversion regression testing, no changes in generated sources.
I'll merge the file with latest version and... - 11:35 AM Feature #1920: implement persistent procedures
- Fixed attribute access when there are extent widgets, like:...
- 11:10 AM Feature #2082 (Closed): add conversion support for 4GL's duplicate variable "feature"
- 10:59 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Committed to bzr revision 10255.
- 10:54 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Check it in and distribute it.
- 10:33 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- The update has passed conversion regression testing. Note that even MAJIC had two cases of duplicated vars, in two fi...
- 09:10 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Added comment and fixed the proc/function case. I'm putting it back into conversion regression testing.
- 09:05 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- Please put a comment into the variable_definitions.rules about the order of the definitions and that we deliberately ...
- 09:03 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- > 1. Is there any difference in behavior when the non-global define variable is inside a nested scope (e.g. an intern...
- 08:58 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- The code looks good. I only have 2 questions:
1. Is there any difference in behavior when the non-global define v... - 08:42 AM Feature #2082 (Review): add conversion support for 4GL's duplicate variable "feature"
- Attached update hides all duplicate var defs, only if the first one is DEF NEW GLOBAL SHARED. I'm putting this throug...
- 08:19 AM Feature #2082: add conversion support for 4GL's duplicate variable "feature"
- 4GL allows two vars with the same name, if this construct is encountered:...
- 08:18 AM Feature #2082 (Closed): add conversion support for 4GL's duplicate variable "feature"
- 08:57 AM Bug #2070: BlockManager Action disambiguation
- Commited to bzr as revision number 10254.
- 08:35 AM Bug #2070: BlockManager Action disambiguation
- The update has passed conversion regression testing, go ahead and distribute it.
- 07:36 AM Bug #2070: BlockManager Action disambiguation
- Added update
- 07:35 AM Bug #2070: BlockManager Action disambiguation
- Please remove the dangling text from the 421 and the other edits I mentioned, and re-upload. I'm putting it through c...
- 07:11 AM Bug #2070: BlockManager Action disambiguation
- Added fix update
- 06:50 AM Bug #2070: BlockManager Action disambiguation
- 0305d.zip doesn't fully solve the issue, as the package name is computed wrong. It uses the package from the nearest ...
- 08:47 AM Bug #2069 (Closed): Accumulator temp table field disambiguation
- 08:27 AM Feature #2079 (Closed): add missing conversion support for format string
- 08:08 AM Feature #2078 (Closed): provide support for malformed label names
- 01:52 AM Feature #2078: provide support for malformed label names
- Committed to bzr revision 10247.
- 07:14 AM Feature #1885: fix and add necessary format string support
- 0306a.zip was Committed to bzr revision 10252.
- 04:45 AM Feature #1885: fix and add necessary format string support
- 0306a.zip has passed conversion regression testing (no changes in generated sources).
- 02:32 AM Feature #1885: fix and add necessary format string support
- Correct version of progress.g
- 02:16 AM Feature #1885: fix and add necessary format string support
- This version emits the toStringMessage in case the format is a complex expression, for PUT field. Also, adds a TODO i...
03/05/2013
- 06:02 PM Feature #2078: provide support for malformed label names
- I'm OK with the code. You can check it in and distribute.
- 05:15 PM Feature #2078: provide support for malformed label names
- Passed conversion regression testing.
- 04:18 PM Feature #2078: provide support for malformed label names
- I'm putting this through conversion regression testing.
- 04:09 PM Feature #2078: provide support for malformed label names
- In 4GL, it is possible to support malformed label names, as in:...
- 04:03 PM Feature #2078 (Hold): provide support for malformed label names
- 05:24 PM Feature #1885: fix and add necessary format string support
- Yes, using toStringMessage() is a great idea.
- 05:04 PM Feature #1885: fix and add necessary format string support
- This fixes the conversion problem, still need to expand PutField c'tors to accept character for the format... or, can...
- 04:38 PM Feature #1885: fix and add necessary format string support
- There is at least one format string problem in the server. Looks like PUT fields can have a dynamic format, and any e...
- 04:41 PM Feature #2079: add missing conversion support for format string
- This is for tracking the time for adding conversion support. All comments to be added in the parent #1885 task.
- 04:40 PM Feature #2079 (Closed): add missing conversion support for format string
- 04:35 PM Bug #2070 (Closed): BlockManager Action disambiguation
- Passed conversion testing and checked into bzr as revision 10244.
- 03:05 PM Bug #2070: BlockManager Action disambiguation
- I'm conversion testing this now.
- 02:56 PM Bug #2070: BlockManager Action disambiguation
- Added cs_upd20130305d.zip only with changes from previous update
- 02:55 PM Bug #2070: BlockManager Action disambiguation
- Commited cs_upd20130305c.zip to bzr as revision number 10243.
- 02:34 PM Bug #2070: BlockManager Action disambiguation
- In cs_upd20130305d.zip, please remove the unchanged files from cs_upd20130305c.zip and add a history entry to control...
- 02:32 PM Bug #2070: BlockManager Action disambiguation
- cs_upd20130305c.zip has passed conversion testing. Check it in and distribute it. I will look at cs_upd20130305d.zi...
- 02:05 PM Bug #2070: BlockManager Action disambiguation
- Added proposed update
- 01:11 PM Bug #2070: BlockManager Action disambiguation
- This is a problem indeed, the solution would be to explicitly import the DMO class.
- 12:23 PM Bug #2070: BlockManager Action disambiguation
- Costin, please double check this, because I think we need to disambiguate this in the opposite direction too, as I th...
- 11:41 AM Bug #2070: BlockManager Action disambiguation
- I'm conversion testing this now.
- 11:32 AM Bug #2070: BlockManager Action disambiguation
- Copied a wrong update deleted wrong file and uploaded the correct one
- 11:27 AM Bug #2070: BlockManager Action disambiguation
- merge
- 11:08 AM Bug #2070: BlockManager Action disambiguation
- The code looks good. Constantin will be checking in 1 more version of common-progress. Merge with that and we will ...
- 09:37 AM Bug #2070: BlockManager Action disambiguation
- merge
- 05:07 AM Bug #2070: BlockManager Action disambiguation
- Added proposed update
- 07:12 PM Bug #2070: BlockManager Action disambiguation
- Code Review:
1. Please merge up to the latest bzr level.
2. This method:... - 03:34 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- ExpressionConversionWorker never returns the int type (e.g. ATTR_POLY) but instead will return the wrapper class name...
- 02:36 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Trying to get the rules to create a new variable with the same field type to apply only for expression type ATTR_POLY...
- 11:12 AM Bug #2069: Accumulator temp table field disambiguation
- Greg Shah wrote:
> Check it in and distribute.
Committed to bzr revision 10242.
> Should we still test ca_upd20... - 11:02 AM Bug #2069: Accumulator temp table field disambiguation
- Check it in and distribute.
Should we still test ca_upd20130304b.zip by itself or should we include these other ch... - 10:03 AM Bug #2069: Accumulator temp table field disambiguation
- 0305b.zip has passed conversion regression testing.
- 09:17 AM Bug #2069: Accumulator temp table field disambiguation
- Another side-note for this task: we should identify all missing no-reference cases and code them in common-progress.r...
- 08:47 AM Bug #2069: Accumulator temp table field disambiguation
- I've fixed the history entry in common-progress.rules.
- 08:39 AM Bug #2069: Accumulator temp table field disambiguation
- Greg Shah wrote:
> Go ahead and check these in and distribute them. If Eric has concerns we will address them in a ... - 08:29 AM Bug #2069: Accumulator temp table field disambiguation
- Another case of no-reference is:...
- 08:18 AM Bug #2069: Accumulator temp table field disambiguation
- Go ahead and check these in and distribute them. If Eric has concerns we will address them in a separate distributio...
- 05:14 AM Bug #2069: Accumulator temp table field disambiguation
- In the end, I ended up testing (using 10237 as baseline, but this should make no difference):
# 05a (INPUT function ... - 11:41 PM Bug #2069: Accumulator temp table field disambiguation
- This makes the INPUT function to produce no-references. About 04c.zip: my test was without 04b.zip update, to better ...
- 10:48 PM Bug #2069: Accumulator temp table field disambiguation
- With these changes, pmcli/ converts fully. Also, MAJIC converts fully, but there is a CAN-FIND change in a single fil...
- 07:01 PM Bug #2069: Accumulator temp table field disambiguation
- Does this resolve #1985 note 64 or is this just more fixes on the way to the Mad Hatter's tea party?
03/04/2013
- 06:46 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- Passed conversion testing and checked in to bzr as revision 10239.
- 05:04 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- New version of the update with another change to the parser that fixes a problem found in testing the server code. I...
- 03:32 PM Feature #2050: ATTR_POLY/METH_POLY used as rvalue or in expressions
- #1985 note 96 shows a new problem: DB_REF_NON_STATIC needs to be supported. I have added it to the ECW. It uses con...
- 04:38 PM Bug #2069: Accumulator temp table field disambiguation
- This fix attempt does the following:
# fixes #2059 's ecf_upd20130303b.zip, to include temp-tables too
# fixes a bu... - 03:59 PM Bug #2069: Accumulator temp table field disambiguation
- Constantin Asofiei wrote:
> This code tests only for BUFFER nodes, and excludes tables, temp-tables, work-tables. Wa... - 03:39 PM Bug #2069: Accumulator temp table field disambiguation
- Some news about the field name disambiguation issue. In SchemaDictionary.promoteEntry, there is this test:...
- 03:17 PM Bug #2069: Accumulator temp table field disambiguation
- Committed to bzr revision 10238.
These files have changes which are not limitted to just buffer scope:... - 03:01 PM Bug #2069: Accumulator temp table field disambiguation
- Check it it and distribute it. I will make sure runtime regression testing is run separately. What programs should ...
- 02:48 PM Bug #2069: Accumulator temp table field disambiguation
- Conversion regression testing has finished, the note about runtime regression testing still stands, with the addition...
- 01:52 PM Bug #2069: Accumulator temp table field disambiguation
- The code looks good.
It also fixes all remaining issues in #1985 notes 93, 104-109 and 111. These programs all co... - 01:27 PM Bug #2069: Accumulator temp table field disambiguation
- Looks like the matching in accumulators needs to be done using the bufname too, attached update does this. I'm puttin...
- 12:25 PM Bug #2069: Accumulator temp table field disambiguation
- > In my example, both fields have a schemaname of "tt.num" but the bufname will differ ("b1" vs "b2"). Actually, the...
- 12:18 PM Bug #2069: Accumulator temp table field disambiguation
- I don't think schemaname alone will work.
In my example, both fields have a schemaname of "tt.num" but the bufname... - 12:09 PM Bug #2069: Accumulator temp table field disambiguation
- The 0304a.zip passed conversion regression testing, but there are lots of buffer scope-related changes, as the accum ...
- 11:41 AM Bug #2069: Accumulator temp table field disambiguation
- If the parser gets the schemaname right, in case of unqualified field and compilable 4GL code, I don't think we will ...
- 11:15 AM Bug #2069: Accumulator temp table field disambiguation
- The changes look good, though we may have to work off something different than only schemaname....
- 10:06 AM Bug #2069: Accumulator temp table field disambiguation
- This update:
* makes the field in accum function to be a no-reference.
* fixes CAN-FIND function, when its WHERE cl... - 09:57 AM Bug #2069: Accumulator temp table field disambiguation
- About the ACCUM no_reference: after I let this be a no_reference, then the "refid" annotation will not be emitted for...
- 09:41 AM Bug #2069: Accumulator temp table field disambiguation
- Please prepare the ACCUM no_reference and CAN-FIND changes and upload the update ASAP. Both of these seem to be corr...
- 12:38 PM Bug #2076: DMO setter fails when parameter is BaseDataType
- Example:...
- 12:34 PM Bug #2076 (Closed): DMO setter fails when parameter is BaseDataType
- 11:32 AM Bug #2070: BlockManager Action disambiguation
- Added the proposed update
- 10:53 AM Bug #2075: unknown literals in nested expressions
- See #2053 where we are creating a parameter type lookup facility for builtin funcs and methods.
- 10:20 AM Bug #2075: unknown literals in nested expressions
- > One of the things I was interested in using the signature data for was during expression typing (we could know exac...
- 09:52 AM Bug #2075: unknown literals in nested expressions
- > Go ahead and commit the change and distribute it.
Committed to bzr revision 10237.
> If I understand properly, ... - 09:46 AM Bug #2075: unknown literals in nested expressions
- Go ahead and commit the change and distribute it.
If I understand properly, we are about to have compile issues wi... - 09:28 AM Bug #2075: unknown literals in nested expressions
- > The question: how much code do we have that is dependent upon this unintended result? I prefer to cleanup the pars...
- 09:07 AM Bug #2075: unknown literals in nested expressions
- Actually, I am worried that the problem is really in how the parser leaves the tree. A pretty important rule about t...
03/03/2013
- 03:40 PM Bug #2069: Accumulator temp table field disambiguation
- Some final notes for today:
# the @CREATE real@ statement produces a free reference, same as a @FIND FIRST real@. If... - 12:32 PM Bug #2069: Accumulator temp table field disambiguation
- Good information in note 3.
1. You have proven that the ACCUM() function parameters are not free references, they ... - 06:40 AM Bug #2069: Accumulator temp table field disambiguation
- First of all, looks like ACCUM function should not produce free-references, because if it did produce, then the code ...
- 11:46 AM Bug #2075: unknown literals in nested expressions
- The fix has passed conversion regression testing.
- 08:06 AM Bug #2075: unknown literals in nested expressions
- P2J fails to convert this case:...
- 07:22 AM Bug #2075 (WIP): unknown literals in nested expressions
Also available in: Atom