Re: [Oorexx-devel] C++ Question
On Wed, Mar 17, 2010 at 9:10 AM, Brandon Cherry wrote: > No wonder I could not find a sample. I was searching for "attribute" or > "method". Thanks! You might also want to look at the ooDialog code, it has all been converted to use the C++ API, although most of the code itself is not object orientated. Similar to this: context->SendMessage1(self, "SQLRETURN=", context->Int32ToObject(0)); In ooDialog.cpp around line 2309: context->SendMessage1(self, "CHILDDIALOGS=", rxNewList(context)); // self~childDialogs = .list~new context->SendMessage0(self, "INITAUTODETECTION"); // self~initAutoDetection context->SendMessage1(self, "DATACONNECTION=", context->NewArray(50)); // self~dataConnection = .array~new(50) context->SendMessage1(self, "AUTOMATICMETHODS=", rxNewQueue(context)); // self~autoMaticMethods = .queue~new -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] OLE-to-Rexx interface?
That's an interesting idea. I haven't given much thought to it yet. But I think the OLEObjectEvent COM object has laid some of the ground work for this. That object already allows OLE objects to call into Rexx and takes a Rexx object and returns it (transformed to an OLE object.) I'm not saying use that object, we'd need to write a new COM object, just saying that code would give us a bit of a starting point. -- Mark Miesfeld On Sat, Mar 13, 2010 at 7:19 AM, Rick McGuire wrote: > The recent question about calling Rexx scripts from Excel makes me > wonder if something like what Rony did with BSF4Rexx might be possible > with the OLE object support. Right now, the OLE object support starts > with Rexx and goes out to the OLE objects. It might be nice to go the > other way. For example, having a Rexx environment OLE object that > would allow you to invoke ooRexx scripts would be a good first start. > Ideally, you 'd want to be able to pass OLE object instances into the > scripts, so an appropriate level of marshalling would be required. > Eventually, I suspect you'd want the ability to pass proxies to Rexx > objects back to the native OLE code. > > Rick > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx Documentation
The only problem I see with this is that in the ooDialog documentation the text I use in the link is very often either not a title, or not the text of the title. At least in the documentation I'm writing myself. For example: This class is deprecated. The ooDialog framework no longer makes a distinction between some types of dialog controls Neither of those links would work for that type of transformation. We'd get a sentence like: The ooDialog framework History makes a distinction between some types of dialog controls. I rarely write: See xxx We could see how it works though. Yesterday I would have jumped at this.But now that I know how to locate the offending hyperref, my frustration has eased considerably. -- Mark Miesfeld On Wed, Mar 3, 2010 at 2:22 PM, Jean-Louis Faucher wrote: > The number of links to update seems high (I found more than 2000 linkend in > oodialog, assuming all are candidate for update). Proposition : I can > modify the script transformdir in DocMusings to apply these transformations > for endterm. > > By default, this script creates a clone of the directory passed as argument > (zero diff). I can add the option -endterm, and apply theses > transformations, described by David : > > Give an id "parentid.title" to each title (parent can be a chapter, a > section, ...). Ex : > > AdvancedControls Class > becomes : > id="clsAdvancedControls.title">AdvancedControls Class > > Add an attribute endterm to each link and remove the child text. Ex : > > See the chapter Advanced > Controls for more information. > becomes : > See the chapter endterm="clsAdvancedControls.title" /> for more information. > > That works only if the target of a linkend is always a title. If this is not > the case, then the doc build will complain and we can adapt the script to > support the other cases. > > Let me know if you are interested. > > Jean-Louis > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx Documentation
On Wed, Mar 3, 2010 at 11:15 AM, Rick McGuire wrote: > On Wed, Mar 3, 2010 at 2:13 PM, David Ashley > wrote: >> >> There are some mass updates I want to perform to the ooRexx >> Documentation. None of them are critical but they will make thing a >> little easier and more obvious to the uninitiated. >> ... > > There's already a 4.0.1 branch of the docs, so the trunk version is > wide open for updates if you wish to start. That's good David. We'll just need to coordinate a little since I'm making big changes to the ooDialog doc and I don't always have it all committed. You could maybe leave the oodialog directory alone and I'll watch what you're doing and do the same for oodialog. Or, let me know in advance when you are going to start, I'll commit any current work I have, and then wait until you're finished. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] (Solved) docbook and ooDialog documentation problems
David,
Thanks, that's a good solution. We all live and learn.
As you'll see in a later post I made, my biggest problem was finding
*which* link was the problem one. I finally figured out how to do
that.
Your solution is a good one to know about. That should help me in the future.
--
Mark Miesfeld
On Wed, Mar 3, 2010 at 9:53 AM, David Ashley wrote:
> There is a way to fix this problem. Unfortunately it would require a LOT
> OF WORK to fix it for everything abd every possibility. And I will take
> the blame for this one. I did not realize when I first started to
> convert the dosuments to sgml/xml that this problem was possible, but
> live an learn I guess.
>
> In any case here is the solution.
>
> First, change the target of a link from its current form. here is an
> example.
>
> This is the original version.
>
> AdvancedControls Class
>
> Here is the modified version.
>
> id="clsAdvancedControls.title">AdvancedControls Class
>
> The label is the text you want to use to refer to the chapter/section.
>
> Now change the link.
>
> Here is an original example.
>
> See the chapter Advanced
> Controls for more information.
>
> Here is the corrected example.
>
> See the chapter endterm="clsAdvancedControls.title" /> for more information.
>
> Note that the endterm causes the text of the title to be substituted at
> the link's location. Thus there is no text that will cross a page
> boundary. This technique can be used on any tag and has the added
> benefits in the output pdf. This should have been the methodology used
> from the very beginning, but I didn't know enough at the time to add
> this little magic. In any case, feel free to fix things using this
> methodology as they come up.
>
> David Ashley
>
> On 03/03/2010 11:08 AM, Mark Miesfeld wrote:
>> On Wed, Mar 3, 2010 at 8:24 AM, Mark Miesfeld wrote:
>>
>>> On Wed, Mar 3, 2010 at 8:00 AM, Mark Miesfeld wrote:
>>>
>>>
>>>> Looking back at the last time I posted about this, I see that there is
>>>> this solution:
>>>>
>>>> This happens when hyperref is used under pdftex and a citation splits
>>>> across a page boundary. To fix it, note the page number of the error
>>>>
>> Okay, I got this fixed. Here's the solution in case any one else runs
>> into this.
>>
>> When the build finishes with this error there will be an *.out file.
>> oodialog.out in this case, I'm assuming it would be rexxref.out or
>> rexxpg.out, etc..
>>
>> I catted oodialog.out and the last lines look like this:
>>
>> \BOOKMARK [3][-]{10.68.422.19.3}{7.9.1.2. addButton}{10.68.422.2}
>> \BOOKMARK [3][-]{10.68.422.20.3}{7.9.1.3. addBitmapButton}{10.68.422.2}
>>
>> I then went to the *.sgml file for the addBitmapButton section. For
>> the links in that section, I changed any that were more than 1 word,
>> to just be 1 word. On the premise that a 1 word link would not cross
>> a page boundry. Like this:
>>
>> image list
>>
>> changed to:
>>
>> image list
>>
>> That worked.
>>
>> Of course, I'd really like the link above to use the two words. And I
>> changed about 4 links in the section when it was probably only 1 link
>> that needed to be changed. But, at least this is a pretty quick way
>> to go forward.
>>
>> In general, I guess only using 1 word in any link would probably
>> prevent this error.
>>
>> --
>> Mark Miesfeld
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] (Solved) docbook and ooDialog documentation problems
On Wed, Mar 3, 2010 at 8:24 AM, Mark Miesfeld wrote:
> On Wed, Mar 3, 2010 at 8:00 AM, Mark Miesfeld wrote:
>
>> Looking back at the last time I posted about this, I see that there is
>> this solution:
>>
>> This happens when hyperref is used under pdftex and a citation splits
>> across a page boundary. To fix it, note the page number of the error
Okay, I got this fixed. Here's the solution in case any one else runs
into this.
When the build finishes with this error there will be an *.out file.
oodialog.out in this case, I'm assuming it would be rexxref.out or
rexxpg.out, etc..
I catted oodialog.out and the last lines look like this:
\BOOKMARK [3][-]{10.68.422.19.3}{7.9.1.2. addButton}{10.68.422.2}
\BOOKMARK [3][-]{10.68.422.20.3}{7.9.1.3. addBitmapButton}{10.68.422.2}
I then went to the *.sgml file for the addBitmapButton section. For
the links in that section, I changed any that were more than 1 word,
to just be 1 word. On the premise that a 1 word link would not cross
a page boundry. Like this:
image list
changed to:
image list
That worked.
Of course, I'd really like the link above to use the two words. And I
changed about 4 links in the section when it was probably only 1 link
that needed to be changed. But, at least this is a pretty quick way
to go forward.
In general, I guess only using 1 word in any link would probably
prevent this error.
--
Mark Miesfeld
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] docbook and ooDialog documentation problems
On Wed, Mar 3, 2010 at 8:00 AM, Mark Miesfeld wrote:
> Looking back at the last time I posted about this, I see that there is
> this solution:
>
> This happens when hyperref is used under pdftex and a citation splits
> across a page boundary. To fix it, note the page number of the error
> and specify the draft option to hyperref so you get an output PDF.
> Then you can see the citation in question and rewrite to fix it.
> (Thanks to James Bednar's posting on the pdftex list about this.)
>
> David, or maybe Jean-Louis, do either of you know how to accomplish the above?
>
> How do you figure out the "page number of the error" ?
>
> Do you specify "the draft option" in the hyperref.cfg file?
Following up on this, I did manage to specify the draft option in the
hyperref.cfg file. I used this syntax:
\PassOptionsToPackage{draft=true}{hyperref}
It produces a PDF with no links in it. Now if someone knows how to
determine the "page number" of the error, I'd be all set. ?
--
Mark Miesfeld
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] docbook and ooDialog documentation problems
Looking back at the last time I posted about this, I see that there is
this solution:
This happens when hyperref is used under pdftex and a citation splits
across a page boundary. To fix it, note the page number of the error
and specify the draft option to hyperref so you get an output PDF.
Then you can see the citation in question and rewrite to fix it.
(Thanks to James Bednar's posting on the pdftex list about this.)
David, or maybe Jean-Louis, do either of you know how to accomplish the above?
How do you figure out the "page number of the error" ?
Do you specify "the draft option" in the hyperref.cfg file?
Thanks for any help on this. Without some way of locating the
offending link, it takes an impossible amount of time to track it
down.
--
Mark Miesfeld
On Wed, Mar 3, 2010 at 7:41 AM, Mark Miesfeld wrote:
> Once again I'm having lots of problems with updating the ooDialog
> documentation. It's that stupid end link ended up at a different
> nesting level than the start link.
>
> The last time this happened, it took me days to fix it.
>
> David, is there any way to figure out where in the text this is
> happening from the output ???
>
> [341.0.31] [342.0.31] [343.0.31] [344.0.31] [345.0.31] [346.0.31] [347.0.31]
> [348.0.31] [349.0.31] [350.0.31] [351.0.31] [352.0.31] [353.0.31] [354.0.31
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
> \pd
> fstartlink.
>
> \endgroup \...@typeset@protect
> l.210776 ... not used.\endSeq{}\endNode{}\endPar{}
> \endDisplayGroup{}\endNode...
>
> ! ==> Fatal error occurred, no output PDF file produced!
>
>
> If you need to look at the whole log, here is a link:
>
> http://build.oorexx.org/builds/docs/5668/docs-buildrpt.txt
>
> --
> Mark Miesfeld
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] docbook and ooDialog documentation problems
Once again I'm having lots of problems with updating the ooDialog
documentation. It's that stupid end link ended up at a different
nesting level than the start link.
The last time this happened, it took me days to fix it.
David, is there any way to figure out where in the text this is
happening from the output ???
[341.0.31] [342.0.31] [343.0.31] [344.0.31] [345.0.31] [346.0.31] [347.0.31]
[348.0.31] [349.0.31] [350.0.31] [351.0.31] [352.0.31] [353.0.31] [354.0.31
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\endgroup \...@typeset@protect
l.210776 ... not used.\endSeq{}\endNode{}\endPar{}
\endDisplayGroup{}\endNode...
! ==> Fatal error occurred, no output PDF file produced!
If you need to look at the whole log, here is a link:
http://build.oorexx.org/builds/docs/5668/docs-buildrpt.txt
--
Mark Miesfeld
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Bug fix status (and crash)
On Mon, Mar 1, 2010 at 7:27 AM, Mark Miesfeld wrote: > Okay, I'll look at the queue ones tonight when I get back on a 64-bit Windows. I re-ran the 4.0.1 test suite on 64-bit XP last night and had no failures. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Bug fix status (and crash)
Okay, I'll look at the queue ones tonight when I get back on a 64-bit Windows. Since Rainer didn't see those failures on 64-bit AIX, maybe I have something set up wrong. -- Mark Miesfeld On Mon, Mar 1, 2010 at 3:53 AM, Rick McGuire wrote: > I only got a single failure running this in 32-bits (the > METHOD.testGroup one). This needed some updates to the oorexxapi > header file for the new release. > > Rick > > On Sun, Feb 28, 2010 at 11:25 PM, Mark Miesfeld wrote: >> On Sun, Feb 28, 2010 at 2:14 PM, Rick McGuire wrote: >> >>> I got a different crash running the 32-bit build, but since the cause >>> was a memory overlay, I'm pretty sure this is the same root cause as >>> your crash. The bug was in the test cases, not the interpreter. I've >>> merged the fix into the 4.0.1 test branch. >> >> Yes that did indeed clear up the crash. >> >> I get 5 test cases failing, 4 in API\classic\CLASSIC.testGroup and 1 >> in API\oo\METHOD.testGroup. I'll look at those tomorrow. >> >> -- >> Mark Miesfeld >> >> -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Bug fix status (and crash)
On Sun, Feb 28, 2010 at 2:14 PM, Rick McGuire wrote: > I got a different crash running the 32-bit build, but since the cause > was a memory overlay, I'm pretty sure this is the same root cause as > your crash. The bug was in the test cases, not the interpreter. I've > merged the fix into the 4.0.1 test branch. Yes that did indeed clear up the crash. I get 5 test cases failing, 4 in API\classic\CLASSIC.testGroup and 1 in API\oo\METHOD.testGroup. I'll look at those tomorrow. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Bug fix status (and crash)
All,
Okay I finished up everthing I wanted to merge into the 4.0.1 branch.
I branched the 4.0.0 release version of ooTest to 4.0.1. (trunk has
at least a few thing in it that are not in 4.0.1)
I built a non-debug version of 4.0.1 on XP 64-bit. It produces a
crash in the interpreter during the API tests. I don't have time to
investigate more today.
Rick - since the interpreter is a non-debug version, I'm not sure the
stack trace helps, but in case it does:
> orxclassic.dll!RexxThreadContext_::Int32ToObject(int i=0x)
> Line 925C++
orxclassic.dll!RexxMethodContext_::Int32ToObject(int i=0x)
Line 1580 C++
orxclassic.dll!TestPullFromQueue_impl(RexxMethodContext_ *
context=0x000ac930, const char * qname=0x070ecfc8)
Line 122C++
orxclassic.dll!TestPullFromQueue(RexxMethodContext_ *
context=0x000ac930, ValueDescriptor *
arguments=0x000ac960) Line 116 C++
rexx.dll!00310068()
[Frames below may be incorrect and/or missing, no symbols loaded for
rexx.dll]
rexx.dll!0031135c()
rexx.dll!002cbb13()
Unhandled exception at 0x027f2ce2 (orxclassic.dll) in rexx.exe:
0xC005: Access violation reading location 0x61746164207c.
Locals:
- this0x617461642074 {instance=??? functions=???
} RexxThreadContext_ * const
instanceCXX0017: Error: symbol "" not found
functions CXX0017: Error: symbol "" not found
i 0x int
--
Mark Miesfeld
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Bug Fixes
Hi Walter, No you don't have to do anything. We are getting ready to do a bug fix release. The messages are generated automatically by SourceForge. We will announce a beta period for the release, which will be 4.0.1. You can test your bugs on the beta if you want. -- Mark Miesfeld On Sat, Feb 27, 2010 at 12:27 PM, Walter Pachl wrote: > Thanks Mark for seeing my long-ago bugs through to Fixed. > I don't have to do anything, do I? > In them good old times I would have regression tested :-) > Walter > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] 4.0.1 bug fix release
Okay, I think the docs are all updated for the 4.0.1 release now. I've committed what I intend to in the ooDialog section. (I've also closed all the documentation bugs that were in 4.0.0 or earlier.) I still have a number of bug fixes I need to merge into the branch. I'll have to do those tonight or maybe tomorrow morning. I'll post when I'm finished. At that point, we could do a first build. My participation in the builds will most likely be a little bit spotty, I have too much on my plate right now. The Windows builds shouldn't be a problem. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] 4.0.1 Docs
Oh, okay. I was confused. I'll fix up anything that needs to done in the oodialog directory. -- Mark Miesfeld On Thu, Feb 25, 2010 at 12:07 PM, David Ashley wrote: > Sorry, I left out that little detail. They were the 4.0.1 branch was > created from the 4.0.0 release. I then merged it with the docs trunk. > > Sorry about the confusion. > > David Ashley > > On 02/25/2010 01:27 PM, Mark Miesfeld wrote: >> David, >> >> This is the same message I sent to the svn notice. >> >> Hmm ... >> >> I'm not sure if I follow what you are doing here David. >> >> Shouldn't the 4.0.1 docs have been branched from the 4.0.0 release >> docs? Since there are no real changes in the bug fix, the docs should >> pretty much remain the same as the 4.0.0 release docs. >> >> There may have been a couple of doc fixes that could then be merged >> into 4.0.1, but there aren't many. >> >> -- >> Mark Miesfeld >> >> On Thu, Feb 25, 2010 at 11:23 AM, David Ashley >> wrote: >> >>> Mark - take special note of this email. >>> >>> All - >>> >>> I created the 4.0.1 branch of the docs today. I then merged in the >>> changes from the docs trunk to that branch (except for oodialog - I will >>> leave that to you, Mark). I used the following scheme to perform the merge. >>> >>> 1. I did NOT modify the makefile! >>> 2. I merged each sgml file that had differences. I did NOT change the >>> graphics file names in the sgml files as I did not want to create a >>> large difference between the 4.0.0 and 4.0.1 docs. >>> 3. As far as I could tell there were no major additions to the docs I >>> merged, only editorial updates. >>> >>> So, except for oodialog, the docs are pretty much ready. >>> >>> David Ashley >>> >>> -- >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> ___ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >> -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] 4.0.1 Docs
David, This is the same message I sent to the svn notice. Hmm ... I'm not sure if I follow what you are doing here David. Shouldn't the 4.0.1 docs have been branched from the 4.0.0 release docs? Since there are no real changes in the bug fix, the docs should pretty much remain the same as the 4.0.0 release docs. There may have been a couple of doc fixes that could then be merged into 4.0.1, but there aren't many. -- Mark Miesfeld On Thu, Feb 25, 2010 at 11:23 AM, David Ashley wrote: > Mark - take special note of this email. > > All - > > I created the 4.0.1 branch of the docs today. I then merged in the > changes from the docs trunk to that branch (except for oodialog - I will > leave that to you, Mark). I used the following scheme to perform the merge. > > 1. I did NOT modify the makefile! > 2. I merged each sgml file that had differences. I did NOT change the > graphics file names in the sgml files as I did not want to create a > large difference between the 4.0.0 and 4.0.1 docs. > 3. As far as I could tell there were no major additions to the docs I > merged, only editorial updates. > > So, except for oodialog, the docs are pretty much ready. > > David Ashley > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] CSelf and mixin classes
On Thu, Feb 25, 2010 at 7:50 AM, Rick McGuire wrote: > I would really prefer not to. This commit makes additions to the API > vector, which also revs the API vector version numbers. That also > means the documentation for this APIs needs to be written, which has > not been done yet. I would really like this to remain just a bug fix > release, as indicated by the version numbers. Okay. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] CSelf and mixin classes
Rick, You had two commits you made with respect to this thread on the list. svn revision: 5103 svn revision: 5159 The first, we said it was pretty debatable that it was a bug, probably not a bug per se. The second we called an enhancement. Would you consider including these in the 4.0.1 release? The reason being, I'd like to be able to provide an ooDialog build from trunk that users could drop into their 4.0.1 install to help with testing, documenting, and finding design flaws. It would need those two commits in 4.0.1 to work. I know, I'm still probably naive to think users will jump in and help, , but they might. I'm all for keeping the release strictly a bug fix release, so I won't push for it if others are against it. But, I don't think there is much risk involved, i.e., it introduces a new bug that we don't catch until after the release. -- Mark Miesfeld On Mon, Aug 24, 2009 at 3:17 PM, Rick McGuire wrote: > Ok, the changes I just committed should fix your problem. The API > problem will be addressed later. > > Rick > > On Mon, Aug 24, 2009 at 7:06 PM, Mark Miesfeld wrote: >> On Mon, Aug 24, 2009 at 3:52 PM, Rick McGuire wrote: >> >>> The code for CSELF searches through all of the scopes of the objects >>> in inheritance order looking for the first occurrence of a CSELF >>> variable in the object, and that occurrence is the value returned for >>> all CSELF references. This is essentially first one found wins, but >>> it is the mechanism that allows subclasses to access the CSELF value >>> defined by the base class. >> >> Okay, that is pretty much what I understood. >> >> So in this definition >> >> ::class 'WindowBase' public mixinclass object >> ::method init_windowBase external "LIBRARY oodialog wb_init_windowBase" >> ::attribute hwnd get external "LIBRARY oodialog wb_getHwnd" >> >> ::class 'DialogControl' public inherit WindowBase WindowExtensions >> >> I expected that a CSELF in a DialogControl method would find the CSELF >> I set in WindowBase, as long as I did not set a CSELF in >> DialogControl. Which is what we want, and does work that way. >> >>> I suspect this really should have been defined by starting with the >>> scope of the current method and searching back along that inheritance >>> chain instead. I would hesitate to call this a bug, but it is >>> something we could add to trunk for the next release. It really is >>> bad for a mixin class to see a CSELF value for anything other than >>> scopes along its own inheritance chain. >> >> Now, if I add a CSELF to DialogControl, I expected my WindowBase code >> to still pick up the WindowBase CSELF and the DialogControl code to >> pick up the DialogControl CSELF. >> >> We don't have to call it a bug, , but it does seem like a good >> thing to change in trunk for the next release. >> >> -- >> Mark Miesfeld >> >> -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] sourceforge bug status updates
On Mon, Feb 22, 2010 at 9:38 AM, Rick McGuire wrote: > Ok, I was thinking I'd change to 4.01 first and work through those, > but your strategy will work better because we have the additional > ability to trach which fixes have been merged. Don't change a thing. > Give a yell when you believe you've finished your triage so I can give > the remaining ones a pass also. Okay, I'm at that point now. There are a few ooDialog bugs left that I may not put in the 4.0.1 release. But I figured you'd leave those alone anyway. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] sourceforge bug status updates
Rick, I was just going to post the strategy I am using. I have a few 'fixe' bugs that I don't want to go into the bug fix release. So, what I did is: * Go through all the pending and close everthing that has made it into a previous release. * Change the group on all the pending that were left to 'next release' * Change the group for the ones I know I don't want in the bug fix to 4.1 At this point, if you filter on status == 'pending' and group == 'next release' you get all the bugs that we have marked as fixed and pending that are "candidates" for the bug fix. Then, as someone actually merges the fix into the 4.0.1 branch he could change the group to 4.0.1. That way we can track which fixes have actually been merged into the 4.0.1 branch. Likewise, if there are any pending bugs that someone does not want to go in the 4.0.1 fix, they could change the group to 4.1 to prevent it. -- Mark Miesfeld P.S. the "mass update" action seems to have some quirks to it, so I had to fix a few things. On Mon, Feb 22, 2010 at 9:25 AM, Rick McGuire wrote: > Mark, > > Thank you for going through and doing the updates on the bug status. > The 4.0 ones really should have been closed right when 4.0 went gold. > Sorry about that oversight. > > For all of the bug fixes tagged with "Next release", I sort of used > that one as a holding pattern rather than targeting those for a > particular release. I sort of assumed we'd have a 4.0.1 release, so I > didn't necessarily want to use a 4.1 tag for items. I think to get > things organized for the 4.0.1 release, this is a good time to start > changing the tags for bug fixes that need to be merged back into the > 4.0.1 release to the more specific 4.0.1 target. > > Rick > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Visual Studio 2008
On Thu, Feb 18, 2010 at 8:31 AM, Rick McGuire wrote: > I'm considering installing VS 2008...are you using that version for > building ooRexx yet? Wondering if there are any issues with using it. Rick, I have VS 2008 on two systems now. There are no problems I've seen. I upgraded to it from 2005 on the main system I work with, so I'm basically using it 95% of the time. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Opinions on setting up a nabble archive account for the oorexx mailing lists.
On Thu, Feb 18, 2010 at 7:03 AM, Mark Miesfeld wrote: > On Thu, Feb 18, 2010 at 6:28 AM, Rick McGuire wrote: > >> I'm considering setting up a nabble account for archiving the oorexx >> mailing lists. One advantage of using nabble is the archive is >> generally internet searchable. The sourceforge archives don't appear > > ... > > It's funny about the SourceForge archives, every so often a search I > do will turn up something from the list. But in general posts on the > list don't show up. From a Google search: SourceForge.net: Open Object Rexx: oorexx-develRe: [Oorexx-devel] Building ooRexx on Windows, Mark Miesfeld wrote: > On Sat, Apr 18, 2009 at 1:19 PM, Mark Miesfeld -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Opinions on setting up a nabble archive account for the oorexx mailing lists.
On Thu, Feb 18, 2010 at 6:28 AM, Rick McGuire wrote: > I'm considering setting up a nabble account for archiving the oorexx > mailing lists. One advantage of using nabble is the archive is > generally internet searchable. The sourceforge archives don't appear > to be. Having the archive set up would give the project a touch more > visibility. Looking for some opinions on whether this should be done > or not. I have no objection, sounds good. It's funny about the SourceForge archives, every so often a search I do will turn up something from the list. But in general posts on the list don't show up. -- Mark Miesfeld -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Question ad "runAs" on Vista and W7
Rony, My short answer is I don't know of anything that will help you here. Longer answer: It's been awhile since I tried very hard on Vista to set up something to make this easier, but I got to the point where I just don't think there is any good solution on Vista. I think things like this are why people don't use Vista. Now, maybe in Windows 7, but I haven't had a chance to use it much. What I did on Vista was create a command prompt icon that was permanently run as Administrator. (Actually two icons, left and right screen.) I do all my work from the command prompt(s) But, this is how I work on every Windows system. For people that don't always work from a command prompt on Windows, which I'm sure is most people, this doesn't help them. Plus, you still have to supply the password when you open the command prompt window(s). Since I always open them when I boot up the system and don't close them, ever, that is not that bad for me. But, there are other problems (for me.) If I mount a shared drive as miesfeld through the GUI, then that drive is not seen from the command prompt, etc., etc.. -- Mark Miesfeld On Wed, Feb 17, 2010 at 3:48 AM, Rony G. Flatscher wrote: > On Vista and Win7 (Rexx) installation scripts sometimes need to change > the registry which may be prohibited by the operating system, unless one > executes the installation scripts with administrator rights. > > To achieve this, one could use the Windows "runAs" program from the > commandline supplying as user "Administrator" and the local machine > name. [This is actually what I have been experimenting with for the > BSF4ooRexx and OOo installation scripts in the past days.] > > Another possibility seems to be the context menu "runAs", which > unfortunately may or may not be avaible on the user's installation. How > would one be able to define this context-menu to rex-scripts? Are there > any reg-files that one can use as a sample (rex-files need to be > executed by rexx.exe, which usually is already defined by the ooRexx > installation) ? > > Is there another possibility which can make this simple for the Vista > and W7 users? A manifest kind of file, and if so, how should it look to > allow scripts to be executed with the Administrator credentials or where > can one learn about it)? > > Any pointers/opinions highly appreciated! > > ---rony > > > > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Bug fix release?
Most definitely. I was thinking this just last night. I'm in the middle of moving to a new house, so my presence on the Internet may be a little hit and miss until I get my computers moved and set up. But, I really think we should do a bug fix release. -- Mark Miesfeld On Fri, Feb 12, 2010 at 7:12 AM, Rick McGuire wrote: > We discussed this some months ago, and decided to hold off until after > the holidays. The Super Bowl is over, thus ending the holiday season > in the US :-) Is it time to start thinking about this again? > > Rick > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Building the ooDialog documentation
I just wanted to give people a heads up that while I'm working on the ooDialog doc for the next couple of weeks, there are sure to be times when what is committed in trunk may not compile. I don't see that as being a problem to any one, except maybe Jean-Louis. On the build machine, If ooDialog.pdf does not build, it does not effect the building of the other doc. If at any time someone is desperate to build the ooDialog pdf, shoot me an e-mail and I'll fix it up so it at least compiles all the way. -- Mark Miesfeld -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile Windows debug version (rev. 5545) from trunk
On Tue, Feb 9, 2010 at 1:15 PM, Rony G. Flatscher wrote: > Hi Mark, > > Maybe one more question: the ooRexx build script makeorx.bat uses "killer > rxapi.exe" to kill rxapi.exe. It now yields the following error: > > F:\work\svn\oorexx\main\trunk>killer rxapi.exe > OpenProcess() failed with error 5 (Zugriff verweigert > ) I also started getting this error on a new system where I installed Visual Studio 2008. The system is XP, at the same level as a number of other XP systems I use where the killer application works fine. I didn't investigate. ;-( But, simply edited my makeorx.bat to use the SysInternals kill utility, which does work. C:\work\wc\main>svn diff makeorx.bat Index: makeorx.bat === --- makeorx.bat (revision 5545) +++ makeorx.bat (working copy) @@ -116,7 +116,7 @@ SET MKDEBUG=0 :STARTBUILD -killer rxapi.exe +pskill rxapi.exe CALL ORXDB %BLDRELEASE% IF ERRORLEVEL 1 GOTO ENV_VARS_CLEANUP C:\work\wc\main> You could get pskill at: www.sysinternals.com which will redirect you to the Microsoft site where you could download it. In thinking about it now, it seems that Visual Studio 2008 may replace the CRT library with one that has some change in it, so that killer does not work. Or it may be an added security thing that crept in. I'll have to take a look. -- Mark Miesfeld -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Building ooRexx on Windows
On Tue, Feb 9, 2010 at 10:26 AM, Mark Miesfeld wrote: > Rony's previous post reminded me that I meant to bring this up on the list. > > To build ooDialog now requires the Windows headers to be at least at > the Vista level. ... Following up on myself. I should have added that the Windows build works fine on the build machine (I just tested it again.) So as long as the build machine is up, anyone can grab a current build from there. Speaking of which, I had wanted to say thanks to David for maintaining the build machine. The last couple of times I used the build machine it worked great. The builds seem to complete much quicker now also. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Building ooRexx on Windows
Rony's previous post reminded me that I meant to bring this up on the list. To build ooDialog now requires the Windows headers to be at least at the Vista level. And, at some point in the future, probably as soon as I get a chance to start working on Windows 7, ooDialog might require the Windows headers to be a the Windows 7 level. ooDialog itself, doesn't require a newer operating system. It will still run on W2K. But, some of the class methods are only available on the newer versions of Windows. Those methods state the requirement in the documentation, and raise syntax conditions if invoked when they are not available. Since the Windows SDKs are free, the build requirement does not seem to me to be a problem. But, it could mean someone has to update their SDK level. Some people might see that as a problem. So, I've been toying with the idea of adding a way to bypass the ooDialog build in the Windows build. It would be simple enough to do. The (amateur ?) builder then could skip building ooDialog if they wanted to by setting an environment variable. They also wouldn't be able to do the packaging step if they skipped building ooDialog. Doesn't anyone think this is worth the effort? -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile Windows debug version (rev. 5545) from trunk
Rony, In order for ooDialog to use features in Windows Vista, the include files need to be at a Vista level (or later.) Since, I think you had already upgraded your Windows SDK to the Vista level, it looks like you need to be sure that the SDK directories are first in the search order. Well, I just rethought this. Normally I say the Windows SDK paths need to be first, before the compiler paths. But actually, what needs to be first is the component that is the most recent. Visual C++ includes a version of the Windows SDK. Before the express editions, since the SDK was free and Visual C++ was not, usually the SDK was more recent. But, I quess this could be reversed now. If you have Visual C++ 2008 Express edition, then when you set up, do the SDK first and Visual C++ second. So, I guess the advice depends on what versions of Visual C++ and the Windows SDK you have. This (free) SDK is sufficient: Windows Vista Update & .NET 3.0 SDK 6.1.6000.16384.10 2007-03-22 or the (free) Visual C++ 2008 Express edition is sufficient. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
On Fri, Feb 5, 2010 at 2:00 AM, Rick McGuire wrote:
> This actually looks better, but I suspect that the hang is now
> occurring because the reentrant windows proc is creating a condition
> where this thread is never getting a chance to be woken up. I didn't
> really expect this chance to make the oodialog problem go way, but
> rather to keep the internal interpreter state from getting corrupted.
Rick,
Yes, the call stacks I looked at did not look as corrupted as they did before.
Below is the thread local storage change that fixes the ooDialog
problem for you to review. (Well along with the change to
relinquish() in Windows that I committed last night.)
* It is confined to Windows dependent files.
* It reuses the old RexxSetProcessMessages() API.
It would have been cleaner, I think, to put the global vaiables needed
in SystemInterpreter. But, since SysSemaphore is linked into
rxapi.dll and rexxapi.exe, the convultions needed to get it to compile
were just too much.
I've tested it yesterday and today, including running the test suite
with and don't see any problems.
Index: interpreter/platform/windows/MiscSystem.cpp
===
--- interpreter/platform/windows/MiscSystem.cpp (revision 5539)
+++ interpreter/platform/windows/MiscSystem.cpp (working copy)
@@ -200,12 +200,19 @@
/**
* This was an undocumented API prior to 4.0, but is known to have been used by
- * some IBM applications. This is maintained solely for binary compatibility.
+ * some IBM applications. Therefore this was maintained solely for binary
+ * compatibility.
*
+ *
+ *
* @return TRUE always.
*/
-BOOL APIENTRY RexxSetProcessMessages(BOOL onoff)
+BOOL APIENTRY RexxSetProcessMessages(BOOL turnOn)
{
- return TRUE;
+if ( ! turnOn )
+{
+TlsSetValue(SysSemaphore::tlsNoMessageLoopIndex, (LPVOID)1);
+}
+return TRUE;
}
Index: interpreter/platform/windows/SystemInitialization.cpp
===
--- interpreter/platform/windows/SystemInitialization.cpp (revision 5539)
+++ interpreter/platform/windows/SystemInitialization.cpp (working copy)
@@ -44,6 +44,7 @@
#include /* Get system, max_path
etc...*/
#include "RexxCore.h"
#include "SystemInterpreter.hpp"
+#include "SysSemaphore.hpp"
/*
*/
@@ -74,12 +75,23 @@
{
if (fdwReason == DLL_PROCESS_ATTACH)
{
+ // Allocate a thread local storage index
+ SysSemaphore::tlsNoMessageLoopIndex = TlsAlloc();
+ if (SysSemaphore::tlsNoMessageLoopIndex == TLS_OUT_OF_INDEXES)
+ {
+ return FALSE;
+ }
+ SysSemaphore::usingTls = true;
+
// perform the interpreter start up
SystemInterpreter::processStartup(hinstDll);
}
else if (fdwReason == DLL_PROCESS_DETACH)
{
SystemInterpreter::processShutdown();
+
+ // Free the thread local storage index
+ TlsFree(SysSemaphore::tlsNoMessageLoopIndex);
}
return TRUE;
}
Index: common/platform/windows/SysSemaphore.cpp
===
--- common/platform/windows/SysSemaphore.cpp(revision 5539)
+++ common/platform/windows/SysSemaphore.cpp(working copy)
@@ -44,6 +44,9 @@
#include "SysSemaphore.hpp"
+bool SysSemaphore::usingTls = false;
+DWORD SysSemaphore::tlsNoMessageLoopIndex = 0;
+
/**
* Create a semaphore with potential creation-time
* initialization.
Index: common/platform/windows/SysSemaphore.hpp
===
--- common/platform/windows/SysSemaphore.hpp(revision 5539)
+++ common/platform/windows/SysSemaphore.hpp(working copy)
@@ -49,46 +49,8 @@
#include
-inline void waitHandle(HANDLE s)
-{
-MSG msg = {0};
+inline void waitHandle(HANDLE s);
-// If already signaled, return.
-if ( WaitForSingleObject(s, 0) == WAIT_OBJECT_0 )
-{
-return;
-}
-
-/** Any thread that creates windows must process messages. A thread that
- * calls WaitForSingelObject with an infinite timeout risks
deadlocking the
- * system. MS's solution for this is to use MsgWaitForMultipleObjects to
- * wait on the object, or a new message arriving in the message
queue. Some
- * threads create windows indirectly, an example is COM with CoInitialize.
- * Since we can't know if the current thread has a message queue
that needs
- * processing, we use MsgWaitForMultipleObjects.
- *
- * Note that MsgWaitForMultipleObjects only returns if a new message is
- * placed in the queue. PeekMessage alters the state of all messages in
- * the queue so that they are no longer 'new.' Once PeekMessage
is called,
- * all the messages on the queue need to be processed.
- */
-do
-{
-while ( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) )
-{
-TranslateMessage(&msg);
-Di
Re: [Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
8a18, _RexxObjectPtr * o=0x070bf990, const char * m=0x000e1790, _RexxArrayObject * a=0x077f9b30) Line 157 C++ > oodialog.dll!RexxThreadContext_::SendMessageA(_RexxObjectPtr * > o=0x070bf990, const char * msg=0x000e1790, _RexxArrayObject * > arr=0x077f9b30) Line 732 C++ oodialog.dll!searchNotifyTable(unsigned __int64 wParam=0x00c8, __int64 lParam=0x029af490, _pbdCSelf * pcpbd=0x075eab10) Line 995 C++ oodialog.dll!searchMessageTables(unsigned long message=0x004e, unsigned __int64 param=0x00c8, __int64 lparam=0x029af490, _pbdCSelf * pcpbd=0x075eab10) Line 1306C++ oodialog.dll!RexxDlgProc(HWND__ * hDlg=0x0022033c, unsigned int uMsg=0x004e, unsigned __int64 wParam=0x00c8, __int64 lParam=0x029af490) Line 146C++ user32.dll!77c34582() user32.dll!77c34bf2() user32.dll!77c5467c() user32.dll!77c43abc() user32.dll!77c4231f() user32.dll!77c423fd() ntdll.dll!77ef318f() user32.dll!77c420fa() user32.dll!77c3feed() user32.dll!77c4341b() comctl32.dll!07ff7f02c802() comctl32.dll!07ff7f073c02() comctl32.dll!07ff7f0748a0() comctl32.dll!07ff7f076146() comctl32.dll!07ff7f078a7b() comctl32.dll!07ff7f078ea5() comctl32.dll!07ff7f076ed8() 000b0048() 0087() 00102300() 000b0048() 00000001() 0081() -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
On Thu, Feb 4, 2010 at 5:40 AM, Rick McGuire wrote: > There's one additional thing we might consider implementing here. The > waiting activities queue is implemented using a linked list where the > link fields are directly contained within the activity object. This > causes problems if there is a reentrant situation that can cause the > same activity to be added to the queue more than once. When that > happens, it's guaranteed bad day. The changes you have proposed can > step around the problem, but won't really close all of the holes where > this situation might occur. It might not be a bad idea to replace > that linked list with a std collection object for managing the > activity queue. With that situation, it doesn't really matter if the > recursion occurs. The internal control blocks will allow an activity > to be queued up multiple times without causing a problem. This > *should* be a simple changeignoring for the moment all of the > problems I had the last time I tried to use a std collection class :-) That sounds good too. Especially if there were some other cases where an external function on an attached thread needed to be reentrant. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
On Thu, Feb 4, 2010 at 1:47 AM, Rick McGuire wrote: > On Wed, Feb 3, 2010 at 11:32 PM, Mark Miesfeld wrote: >> What I was thinking was: for the C++ API, add an API for AttachThread >> that took a parameter which marked the activity for that thread to >> avoid PeekMessage. Them from ActivityManager::addWaitingActivity this >> flag would get passed down to waitKernel() and ultimately >> waitHandle(). > > I'm not really in favor of exposing this bit of Windows-specific > problem in the portable APIs. Maybe the solution is to make the > RexxSetMessageLoop() API functional again, but have it work on a > per-thread basis rather than globally the way it used to. Yeah, I didn't like it too much either. Using thread local storage, the whole thing could be implemented in the Windows specific files, except for how to set the flag on. (If you think of on as being don't use PeekMessage.) Using RexxSetMessageLoop would solve that last part. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
Rick
(For some reason your mail didn't show up until hours after you sent it.)
I have a solution that, so far, in all my testing seems to work. I'm
not sure how to fully implement it, or if it is feasible. It has two
parts:
1.) I think this is feasible and indeed I think should probably be
done in any case. On Windows, the implementation of
SysActivity::relinquish() is this:
void SysActivity::relinquish()
{
MSG msg;
/* If there is a msg in the message queue, dispatch it to the appropriate
* window proc.
*/
if (PeekMessage (&msg, // message structure
NULL, // handle of window
receiving the message
0, // lowest message to examine
0,
PM_REMOVE))// highest message to examine
{
TranslateMessage(&msg);// Translates virtual key codes
DispatchMessage(&msg); // Dispatches message to window
}
}
This looks to me like a hold over from Windows 3.1 non-preemptive
multi-tasking where there was only PeekMessage, GetMessage, and Yield
that would give the processor a chance to run another task. From what
I've seen, a lot of the Windows 95 programming texts encouraged the
programmer to still write "well behaved" applications that yielded the
thread. So, I think this implementation is left over from that era.
I think PeekMessag() could be replaced with Sleep(1) which would allow
any other waiting threads to run.
2.) The other problem is in waitHandle(), which in my looking at this
over the past week is actually the one that usually causes the
problem. There we have PeekMessage() running in a loop:
do
{
while ( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
// Check to see if signaled.
if ( WaitForSingleObject(s, 0) == WAIT_OBJECT_0 )
{
return;
}
}
} while ( MsgWaitForMultipleObjects(1, &s, FALSE, INFINITE,
QS_ALLINPUT) == WAIT_OBJECT_0 + 1 );
The point of this was to process messages in threads that, possibly,
had hidden windows. It wasn't meant for threads that had an active
message pump, as the WindowUsrLoopThread and WindowLoopThread do.
What I was thinking was: for the C++ API, add an API for AttachThread
that took a parameter which marked the activity for that thread to
avoid PeekMessage. Them from ActivityManager::addWaitingActivity this
flag would get passed down to waitKernel() and ultimately
waitHandle().
In waitHandle() sort of pseudo code would be:
inline void waitHandle(HANDLE s, bool noPeek)
{
if ( noPeek )
{
WaitForSingleObject(s, INFINITE);
return;
}
else
{
}
}
(Actually the same flag could be passed to SysActivity::relinquish()
to do a Sleep() instead of a PeekMessage(), I just don't think the
PeekMessage() is needed in that method to begin with.)
What I did as a quick hack to test this was change SysActivity::relinquish to
void SysActivity::relinquish()
{
Sleep(1);
return;
}
and waitHandle() to this:
inline void waitHandle(HANDLE s)
{
WaitForSingleObject(s, INFINITE);
return;
... other code remains, just will never execute
}
and with that I could never reproduce the problem.
I think you are right in that with the current code something
definitely gets corrupted.
Your idea:
> I wonder if we could somehow create a
> thread local variable and keep a flag that would bypass the message
> dispatch when this sort of reentrant situation occurs for a semaphore
> request.
Is essentially the same idea as mine, just marking the thread itself
instead of the activity object. I could probably implement something
like that myself. Marking the activity was a little beyond me.
--
Mark Miesfeld
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Hangs with ooDialog and thread attached to Window Procedure thread
Rick, When you get a chance could you take a look at this problem. I'm going to send you a zip file with some stack traces and a test program. This is related to / similar to the problem we were discussing a week or so ago. Similar in that it has to do with the C++ API and using AttachThread() to be able to directly invoke Rexx methods from the window procedure function (RexxDlgProc) rather than using the 'message queue' as ooDialog was doing. There are several things going on here, so bear with me a bit. 1.) The behavior on 64-bit Windows and 32-bit Windows is markedly different. (The reason you couldn't get my other test program to produce what I saw. As soon as I ran that program on a 32-bit system - it worked fine for me too.) The test program I'm sending now demonstrates the problem on a 32-bit system. 2.) A key problem is that window procedures are re-entrant, something I knew but was not thinking about. What's happening is, a message comes into RexxDlgProc(), the thread context is used for various API calls, at some point when an API call has to wait to get the kernel access, or since there are are several threads going, the thread context activity needs wait its turn to run, we end up in the waitHandle() function in SysSemaphore.hpp running on the RexxDlgProc() thread. During PeekMessage(), the Windows kernel delivers non-queued messages to the windows belonging to the thread by directly invoking the window procedure. So, while the thread context is waiting, RexxDlgProc() gets invoked again, before the processing of the first RexxDlgProc() is finished, (it's at waitHandle().) What you see from the application side is that the dialog stops responding and the program is hung. However, ctrl-c breaks out of the running Rexx program. There is one stack trace, show.rick.64bit, that shows this very clearly if you go to the bottom of the stack and work to the top. I have some ideas about this, but I wanted you to take a look at it first, because ... 3.) When I use the debugger to attach to the process and break into it, the call stacks for the threads look corrupted to me. So, I'm wondering if there is a second problem here. The test program works with the current stuff committed to trunk. It has one control in a dialog, a date time control. When you click on the control and then click on a spot in the dialog, some call back fields in the control get updated. When you do that several times in a row, suddenly the date time field goes blank and at that point the dialog is hung. I've been just using the debugger at this point to attach to the program and look at things. I haven't been running the program under the debugger, but the couple times I did I saw the same thing. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Debugging rexx.exe failures
Wow, you really are using the latest code.
This shows a problem I'm having with ooDialog that I need to discuss
with Rick. It can't have anything to do with your original problem
because it is brand new ooDialog code.
Rick - I'm going to bring this up and discuss it in a separate thread.
--
Mark Miesfeld
On Wed, Feb 3, 2010 at 6:02 AM, David Ruggles wrote:
> After I upgraded to XP with all updates, VS Express 2008 and compiled from
> trunk, I'm getting an error as soon as I attempt to shut the application
> down:
>
> First-chance exception at 0x002e00a3 (rexx.dll) in rexx.exe: 0xC005:
> Access violation reading location 0x02bf28a2.
> Unhandled exception at 0x002e00a3 (rexx.dll) in rexx.exe: 0xC005: Access
> violation reading location 0x02bf28a2.
>
> (Side note here, when the application is running I see tons of the
> First-chance exception Message just scrolling by in the Output window,
> any idea what that means?)
>
> This seems to be the call stack from the error, but there were 18 threads
> running at termination so I'm not 100% sure.
>
>> rexx.dll!RexxList::getFree() Line 148 + 0x14 bytes C++
> rexx.dll!RexxList::insert(RexxObject * _value=0x7f627fb0, RexxObject
> * _index=0x) Line 556 + 0x8 bytes C++
> rexx.dll!RexxList::append(RexxObject * _value=0x7f627fb0) Line 542
> C++
> rexx.dll!RexxNativeActivation::createLocalReference(RexxObject *
> objr=0x7f627fb0) Line 1151 C++
> rexx.dll!ApiContext::ret(RexxObject * o=0x7f627fb0) Line 171 C++
> rexx.dll!UintptrToObject(RexxThreadContext_ * c=0x7f5fd514, unsigned
> int n=1835100) Line 622 + 0x17 bytes C++
> oodialog.dll!RexxThreadContext_::Uintptr(unsigned int n=1835100)
> Line 867 C++
> oodialog.dll!genericCommandInvoke(RexxThreadContext_ * c=0x7f5fd514,
> _pbdCSelf * pcpbd=0x7f5c98c8, const char * methodName=0x000da048, unsigned
> int wParam=1, long lParam=1835100) Line 539 + 0xc bytes C++
> oodialog.dll!searchCommandTable(unsigned int wParam=1, long
> lParam=1835100, _pbdCSelf * pcpbd=0x7f5c98c8) Line 667 + 0x26 bytes C++
> oodialog.dll!searchMessageTables(unsigned long message=273, unsigned
> int param=1, long lparam=1835100, _pbdCSelf * pcpbd=0x7f5c98c8) Line 1277 +
> 0xf bytes C++
> oodialog.dll!RexxDlgProc(HWND__ * hDlg=0x00050036, unsigned int
> uMsg=273, unsigned int wParam=1, long lParam=1835100) Line 146 + 0x13 bytes
> C++
> user32.dll!7e418734()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> user32.dll]
> user32.dll!7e423ce4()
> user32.dll!7e423b30()
> user32.dll!7e43e577()
> user32.dll!7e418734()
> user32.dll!7e418734()
> user32.dll!7e43e577()
> user32.dll!7e43e577()
> user32.dll!7e42b401()
> msctf.dll!747313d4()
> msctf.dll!74730f0f()
> msctf.dll!747313d9()
> user32.dll!7e42b372()
> user32.dll!7e418734()
> user32.dll!7e418816()
> user32.dll!7e4189cd()
> user32.dll!7e4196c7()
> rexx.dll!waitHandle(void * s=0x04d4) Line 83 C++
> rexx.dll!SysSemaphore::wait() Line 104 C++
> rexx.dll!RexxActivity::waitReserve(RexxObject * resource=0x7f5c9328)
> Line 1760 C++
> rexx.dll!RexxVariableDictionary::reserve(RexxActivity *
> activity=0x7f5fd500) Line 377 C++
> rexx.dll!RexxActivation::run(RexxObject * _receiver=0x7f5c91d0,
> RexxString * msgname=0x7f6856c8, RexxObject * * _arglist=0x0170f9e0,
> unsigned int _argcount=2, RexxInstruction * start=0x,
> ProtectedObject & resultObj={...}) Line 440 C++
> rexx.dll!RexxCode::run(RexxActivity * activity=0x7f5fd500,
> RexxMethod * method=0x7ef43a00, RexxObject * receiver=0x7f5c91d0, RexxString
> * msgname=0x7f6856c8, RexxObject * * argPtr=0x0170f9e0, unsigned int
> argcount=2, ProtectedObject & result={...}) Line 136 C++
> rexx.dll!RexxMethod::run(RexxActivity * activity=0x7f5fd500,
> RexxObject * receiver=0x7f5c91d0, RexxString * msgname=0x7f6856c8,
> RexxObject * * argPtr=0x0170f9e0, unsigned int count=2, ProtectedObject &
> result={...}) Line 325 C++
> rexx.dll!RexxObject::messageSend(RexxString * msgname=0x7f6856c8,
> RexxObject * * arguments=0x0170f9e0, unsigned int count=2, ProtectedObject &
> result={...}) Line 793 C++
> rexx.dll!RexxObject::sendMessage(RexxString * message=0x7f6856c8,
> RexxObject * argument1=0x7fcb13f8, RexxObject * argument2=0x7f685628,
> ProtectedObject & result={...}) Line 694 C++
> rexx.dll!RexxObject::sendMessage(RexxString * message=0x7f6856c8,
> RexxObje
Re: [Oorexx-devel] Long Running Program Just Dies
Well, I think the debugger always stops with the the thread that had the exception the current thread. You can tell which thread that is by the little arrow in the thread list window. When I use the debugger, it always stops with the source window showing the location of the exception. It has always been "obvious" where the exception was located. But, I've never used the express edition and from what you said originally, it doesn't seem to work exactly the same. -- Mark Miesfeld On Wed, Feb 3, 2010 at 5:53 AM, David Ruggles wrote: > Is there any obvious way to know which thread caused the exception? > > Thanks, > > David Ruggles > CCNA MCSE (NT) CNA A+ > Network Engineer Safe Data, Inc. > (910) 285-7200 da...@safedatausa.com > > > > -Original Message- > From: Mark Miesfeld [mailto:miesf...@gmail.com] > Sent: Tuesday, February 02, 2010 10:32 AM > To: Open Object Rexx Developer Mailing List > Subject: Re: [Oorexx-devel] Long Running Program Just Dies > > > On Mon, Feb 1, 2010 at 11:19 AM, David Ruggles > wrote: > >> This time I poked around in the GUI and while I couldn't find more the one >> Call Stack I did find a Thread list. > > David, just as a FYI: Double-click on one of the threads in the list > and the debugger switches to that thread. Then what shows in the call > stack window is the stack for that thread. > > -- > Mark Miesfeld > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Build on XP with Visual Studio Express
On Tue, Feb 2, 2010 at 1:38 PM, David Ruggles wrote: > Sorry to waste your time, I left the SRC_DRV set to the example "E:" instead > of changing it to "C:" No problem. These things happen to me all the time. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Build on XP with Visual Studio Express
David, The section that creates the output directories is this: REM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - REM :IS_DEBUG REMSets the variables for a debug build and creates the output directory, if REMneeded. REM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - :IS_DEBUG set MKNODEBUG=0 set MKDEBUG=1 IF %DOPACKAGE% == 1 SET PACKAGE_DBG=1 set OR_OUTDIR=%SRC_DRV%%SRC_DIR%\Win32Dbg set OR_OUTDIR_API=%OR_OUTDIR%\api set OR_ERRLOG=%OR_OUTDIR%\Win32Dbg.log if not exist %OR_OUTDIR% md %OR_OUTDIR% if not exist %OR_OUTDIR_API% md %OR_OUTDIR_API% GOTO BUILD_CHECK_DONE You see the 'if not exist' lines. That is where it would create 2 directories. Then you see this in your output: > No sense in starting if SRC_DIR and SRC_DRV are not set. > Might be needed for a build under Win 2000. > Check that we have at least the first option > If NO_BUILD_LOG is set, do not redirect to a log. > Check for the 'package' option > Check for the type of build > The device is not ready. > The device is not ready. Right there above is where it tried to create the directories, and the OS says there is a problem. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Build on XP with Visual Studio Express
David, "Device is not ready" is an operating system message when it can't write to a disk. It looks like you might have a disk problem. Is the disk full? Doy you have SRC_DRV pointing to a writable disk? I.e., not your DVD drive or a network drive that is not attached? -- Mark Miesfeld On Tue, Feb 2, 2010 at 1:21 PM, David Ruggles wrote: > Yes sir. > > I changed a lot of the REM to ECHOs and I see this: > > No sense in starting if SRC_DIR and SRC_DRV are not set. > Might be needed for a build under Win 2000. > Check that we have at least the first option > If NO_BUILD_LOG is set, do not redirect to a log. > Check for the 'package' option > Check for the type of build > The device is not ready. > The device is not ready. > Figure out the compiler and if this is a 64-bit build. > Print out the args and environment variables to help with debug if the > build does not complete. > 1 E:\Build\ooRexx-trunk\main\Win32Dbg\Win32Dbg.log > The device is not ready. > > The 1 E:\.. Line is where I echo %USELOGFILE% %OR_ERRLOG% right after > :PRINT_OUT_VARS > "The device is not ready" is from where it tries to echo in to %OR_ERRLOG% > and since the Win23Dbg directory doesn't exist it can't > > Thanks, > > David Ruggles > CCNA MCSE (NT) CNA A+ > Network Engineer Safe Data, Inc. > (910) 285-7200 da...@safedatausa.com > > > > -Original Message- > From: Mark Miesfeld [mailto:miesf...@gmail.com] > Sent: Tuesday, February 02, 2010 4:16 PM > To: Open Object Rexx Developer Mailing List > Subject: Re: [Oorexx-devel] Build on XP with Visual Studio Express > > > On Tue, Feb 2, 2010 at 1:08 PM, David Ruggles wrote: > >> I'm trying to build on Windows XP and it doesn't look like it's creating > the >> Win32Dbg directory. I can't find where in makeorx.bat the directory is >> created. If you can point in the right direction I'll continue to debug >> this. > > It gets created automatically when it does a debug build. Are you > using: makeorx DEBUG > > -- > Mark Miesfeld > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Build on XP with Visual Studio Express
On Tue, Feb 2, 2010 at 1:08 PM, David Ruggles wrote: > I'm trying to build on Windows XP and it doesn't look like it's creating the > Win32Dbg directory. I can't find where in makeorx.bat the directory is > created. If you can point in the right direction I'll continue to debug > this. It gets created automatically when it does a debug build. Are you using: makeorx DEBUG -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Long Running Program Just Dies
On Mon, Feb 1, 2010 at 11:19 AM, David Ruggles wrote: > This time I poked around in the GUI and while I couldn't find more the one > Call Stack I did find a Thread list. David, just as a FYI: Double-click on one of the threads in the list and the debugger switches to that thread. Then what shows in the call stack window is the stack for that thread. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx:[5521] incubator/orxcurses
David,
I see a number of these in the commit:
-char buf[n + 1];
+char *buf = (char *)malloc(n + 1);
+RexxObjectPtr tmp;
if (cself == NULL) {
context->RaiseException2(Rexx_Error_Incorrect_method_noclass,
@@ -1634,7 +1638,9 @@
return 0;
}
mvwgetnstr((WINDOW *)cself, SUBTRACTONE(y), SUBTRACTONE(x), buf, n);
-return context->NewStringFromAsciiz(buf);
+tmp = context->NewStringFromAsciiz(buf);
+free(tmp);
+return tmp;
Surely you mean:
tmp =
free(buf)
return tmp
I'm sure you would catch it quick enough, just thought I'd point it
out in case it causes some odd behavior that is hard to debug.
--
Mark Miesfeld
-- Forwarded message --
From:
Date: Sat, Jan 30, 2010 at 4:48 PM
Subject: [Oorexx-svn] SF.net SVN: oorexx:[5521] incubator/orxcurses
To: oorexx-...@lists.sourceforge.net
Revision: 5521
http://oorexx.svn.sourceforge.net/oorexx/?rev=5521&view=rev
Author: wdashley
Date: 2010-01-31 00:48:46 + (Sun, 31 Jan 2010)
Log Message:
---
New tests. The prefresh API seems not to work so I am using a
workaround. Including some code in the header file from Jean-Louis to
support compiling under Windows and PDCurses.
Modified Paths:
--
incubator/orxcurses/ncurses.cls
incubator/orxcurses/orxncurses.cpp
incubator/orxcurses/orxncurses.h
Added Paths:
---
incubator/orxcurses/test11-1.rex
incubator/orxcurses/test11-2.rex
Modified: incubator/orxcurses/ncurses.cls
===
--- incubator/orxcurses/ncurses.cls 2010-01-29 16:18:46 UTC (rev 5520)
+++ incubator/orxcurses/ncurses.cls 2010-01-31 00:48:46 UTC (rev 5521)
@@ -48,7 +48,7 @@
::class Window public
-::ATTRIBUTE stdscr class private
+::ATTRIBUTE stdscr class
-- chtype constants
::CONSTANT A_NORMAL 0
@@ -272,7 +272,8 @@
::METHOD init
if arg() = 0 & .window~stdscr() = 'STDSCR'then do
use strict arg
- .window~stdscr = self~first_init()
+ self~first_init()
+ .window~stdscr = self
end
else if arg() = 1 then do
use strict arg ptr
@@ -542,12 +543,26 @@
::METHOD init EXTERNAL "LIBRARY orxncurses OrxCurNewpad"
-::METHOD echochar EXTERNAL "LIBRARY orxncurses OrxCurPechochar"
-::METHOD pechochar EXTERNAL "LIBRARY orxncurses OrxCurPechochar"
+::METHOD echochar
+return self~ERR
::METHOD mvwin
return self~ERR
+::METHOD pechochar EXTERNAL "LIBRARY orxncurses OrxCurPechochar"
+::METHOD pnoutrefresh EXTERNAL "LIBRARY orxncurses OrxCurPnoutrefresh"
+--::METHOD prefresh EXTERNAL "LIBRARY orxncurses OrxCurPrefresh"
+::METHOD prefresh
+use strict arg minrow, mincol, sminrow, smincol, smaxrow, smaxcol
+.window~stdscr()~copywin(self, minrow, mincol, sminrow, smincol,
smaxrow, smaxcol, .false)
+.window~stdscr()~refresh()
+return self~OK
+::METHOD redrawwin
+return self~ERR
+::METHOD refresh
+return self~ERR
::METHOD scroll
return self~ERR
+::METHOD scrollok
+return self~ERR
::METHOD scrl
return self~ERR
::METHOD subpad
@@ -556,12 +571,6 @@
return .window~new(ptr)
::METHOD subwin
return self~ERR
-::METHOD pnoutrefresh EXTERNAL "LIBRARY orxncurses OrxCurPnoutrefresh"
-::METHOD prefresh EXTERNAL "LIBRARY orxncurses OrxCurPrefresh"
-::METHOD redrawwin
-return self~ERR
-::METHOD refresh EXTERNAL "LIBRARY orxncurses OrxCurPrefresh"
--- ::METHOD subpad EXTERNAL "LIBRARY orxncurses OrxCurSubpad"
::METHOD wnoutrefresh
return self~ERR
Modified: incubator/orxcurses/orxncurses.cpp
===
--- incubator/orxcurses/orxncurses.cpp 2010-01-29 16:18:46 UTC (rev 5520)
+++ incubator/orxcurses/orxncurses.cpp 2010-01-31 00:48:46 UTC (rev 5521)
@@ -1574,7 +1574,8 @@
CSELF, cself, // Self
int, n)
{
- char buf[n + 1];
+ char *buf = (char *)malloc(n + 1);
+ RexxObjectPtr tmp;
if (cself == NULL) {
context->RaiseException2(Rexx_Error_Incorrect_method_noclass,
@@ -1583,7 +1584,9 @@
return 0;
}
wgetnstr((WINDOW *)cself, buf, n);
- return context->NewStringFromAsciiz(buf);
+ tmp = context->NewStringFromAsciiz(buf);
+ free(tmp);
+ return tmp;
}
/**
@@ -1625,7 +1628,8 @@
int, x,
int, n)
{
- char buf[n + 1];
+ char *buf = (char *)malloc(n + 1);
+ RexxObjectPtr tmp;
if (cself == NULL) {
context->RaiseException2(Rexx_Error_Incorrect_method_noclass,
@@ -1634,7 +1638,9 @@
return 0;
}
mvwgetnstr((WINDOW *)cself, SUBTRACTONE(y), SUBTRACTONE(x), buf, n);
- return context->NewStringFromAsciiz(buf);
+ tmp = context->NewStringFromAsciiz(buf);
+ free(tmp);
+ return tmp;
}
/**
@@ -2279,7 +2285,8 @@
CSELF, cself, // Self
int, n)
{
- char buf[n + 1];
+ char *buf =
Re: [Oorexx-devel] Long Running Program Just Dies
On Fri, Jan 29, 2010 at 6:38 AM, Rick McGuire wrote: > Hmmm, when I get a crash with Visual Studio installed, there is a > button enabled that gives the option of debugging the crashing > application. If that's not there, you might try running the > application under the debugger using > > devenv /debugexe rexx myapp.rex arguments I've found that I often have to put the directory that myapp.rex in the path to use the above command line. Something like set PATH=;%PATH% devenv /debugexe rexx myapp.rex arguments But, as Rick said, there really should be a popup message box giving you the option to start the debugger when the crash happens. I'm not sure why that doesn't happen. -- Mark Miesfeld -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Odd OODialog Font Issue
On Thu, Jan 28, 2010 at 8:21 AM, David Ruggles wrote:
> I upgraded from oorexx 3.2 to oorexx 4.0 on a windows 2000 machine. I am
> creating a dialog using a subclass of userdialog with this statement:
> rc = self~create(0, 0, width, height, title, , , , 'MS Sans Serif', 8)
Prior to 4.0 ooDialog's handling of fonts was completely broken. I
opened a bug and attached a program that demonstrates it was broken.
Forget the number right now, but it should be easy to find.
> On 3.2 the font displays as expected, however on 4.0 it doesn't.
>
> Is there a quick fix for this?
This would depend on what you mean by "expected," probably. Since you
are explicitly specifying the font in the create() method, for that
case, I would have expected 3.2.0 and 4.0.0 to behave exactly the
same.
If you could send me a program that demonstrates this, I'll take a
look at why it isn't working as I would expect. Send it to miesfeld
at gmail.
One thing most people don't realize is that when you specify a font,
the Windows font manager creates a logical font that it thinks most
closely matches what is requested. It always gives you a font. But,
if there is no close match, what you actually get could be far
different then what you wanted.
Since I don't have easy access to a W2K box, if it is easy for you to
try, could you see if this same behavior exists on a XP machine?
Well, I wrote the above and then looked more closely at your create()
call. The above is all still valid, but
rc = self~create(0, 0, width, height, title, , , , 'MS Sans Serif', 8)
that looks to have too many commas
rc = self~create(0, 0, width, height, title, options, dlgClass,
fontNameBelongsHereThenNextSouldBeSize, 'MS Sans Serif', 8)
So, your call is incorrect, and who knows what font you are actually
getting. But probably, you are getting System 10. A quick fix could
be to add this to the top of your dialog code:
.PlainBaseDialog~setDefaultFont("System", 10) -- or maybe 8
If, I'm correct in the font you are actually getting, this should also
give your dialog the same appearance:
rc = self~create(0, 0, width, height, title, , , "System", 10) -- or maybe 8
Let me know if that works. If not, I'll need to the example program.
--
Mark Miesfeld
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] terminate called after throwing an instance of 'ActivityException'
On Sun, Jan 24, 2010 at 3:12 PM, Rick McGuire wrote:
> ...
> However,
> that's a different issue from what's causing the test case to fail in
> the first place.
Well, I get stuck in LibraryPackage::getPackageTable. Some method
resolution that I don't understand.
When I run a simple Rexx program:
say 'sqrt:' rxcalcsqrt(4)
::requires 'rxmath' LIBRARY
I see this output:
[miesf...@osprey API]$ rexx qTest.rex
LibraryPackage::getPackagTable() lib.reset succeeded for name=rexxutil
SysLibrary::load() length name=8, name=rexxutil
dlopen librexxutil.so libraryHandle=0x1e5b070
LibraryPackage::getPackagTable() lib.load succeeded for name=rexxutil
LibraryPackage::getPackagTable() lib.reset succeeded for name=rxmath
SysLibrary::load() length name=6, name=rxmath
dlopen librxmath.so libraryHandle=0x1e67be0
LibraryPackage::getPackagTable() lib.load succeeded for name=rxmath
When I run rexxinstance directly I see this output:
[miesf...@osprey API]$ ./rexxinstance INSTANCE -LIB rxmath
"/work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/callMath.rex"
LibraryPackage::getPackagTable() lib.reset succeeded for name=rexxutil
LibraryPackage::getPackagTable() lib.load succeeded for name=rexxutil
LibraryPackage::getPackagTable() lib.reset succeeded for name=rxmath
LibraryPackage::getPackagTable() lib.load failed for name=rxmath
So when I run rexxinstance, SysLibrary::load() does not get invoked.
But something must get invoked, because rexxutil gets loaded.
Maybe some C++ thing I don't understand? Is there some other method
in the interpreter that the call to lib.load would resolve to?
lib.reset();
printf("LibraryPackage::getPackagTable() lib.reset succeeded for
name=%s\n", libraryName->getStringData());
if (!lib.load(libraryName->getStringData()))
{
printf("LibraryPackage::getPackagTable() lib.load failed for
name=%s\n", libraryName->getStringData());
Looks like I'm going to have to give up for today. ;-( Have a dinner
appointment.
--
Mark Miesfeld
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] terminate called after throwing an instance of 'ActivityException'
Rick, I haven't tracked this all the way down yet. But, I'm curious why this doesn't result in the usual Rexx condition message? [miesf...@osprey API]$ ./rexxinstance INSTANCE -LIB rxmath "/work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/callMath.rex" invokeProgram() instance=(nil) context=(nil) ... LOAD_REQUIRED_LIBRARY going to invoke getLibrary PackageManger::loadLibrary() package=(nil) PackageManger::getLibrary() package=(nil) Got to RexxActivity::reportAnException sub=0x7fcdf90046d0 terminate called after throwing an instance of 'ActivityException' Aborted I would have expected something more like this: Got to RexxActivity::reportAnException sub=0x7fbd960e9680 6 *-* ::requires 'rxmLath' LIBRARY REX0098E: Error 98 running /work.ooRexx/ooTest/4.0.0/external/API/qTest.rex line 6: Execution error REX0479E: Error 98.903: Unable to load library "rxmLath" Is it because of the way rexxinstance is written? I.e., it would need to print out the condition message itself, but doesn't because it is just a test program. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] terminate called after throwing an instance of 'ActivityException'
Thanks Rick, As you guessed, my Linux debugging is to trace using printf's. I've worked my way down to PackageManger::getLibrary() [miesf...@osprey API]$ ./rexxinstance INSTANCE -LIB rxmath "/work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/callMath.rex" invokeProgram() instance=(nil) context=(nil) Processed instanceInfo->loadLibray optionName=LoadRequiredLibrary option=rxmath Going to call RexxCreateInterpreter() Interpreter::createInstance() entered Interpreter::createInterpreterInstance() interpreter should be initialized now Interpreter::createInterpreterInstance() got rootActivity=0x7f9ee71e2c90 Interpreter::createInterpreterInstance() got instance=0x7f9ee71e3370 Interpreter::createInterpreterInstance() added instance to the active list Interpreter::createInterpreterInstance() instance now initialized Interpreter::createInterpreterInstance() interpreter should be initialized now Interpreter::createInterpreterInstance() got rootActivity=0x7f9ee71ea240 Interpreter::createInterpreterInstance() got instance=0x7f9ee71ea920 Interpreter::createInterpreterInstance() added instance to the active list LOAD_REQUIRED_LIBRARY got libraryName=0x7f9ee71e46d0 LOAD_REQUIRED_LIBRARY going to invoke getLibrary terminate called after throwing an instance of 'ActivityException' Aborted [miesf...@osprey API]$ A few more iterations and I should be close. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] terminate called after throwing an instance of 'ActivityException'
I'm running the test suite on Linux, Fedora core 10 64-bit to be specific. I get 1 test case error with a pure build of trunk. (I.e., no changes to the code base at all.) [failure] [20100124 13:54:21.251357] svn:r4817 Change date: 2009-06-18 13:10:10 -0700 Test: TESTLOADLIBRARY Class: ProcessInvocation.testGroup File: /work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/ProcessInvocation.testGroup Line: 892 Failed: assertEquals Expected: [[2], identityHash="17492628931590"] Actual: [[The NIL object], identityHash="17492628930280"] This specific test invokes tests/callMath.rex Using a say statement, I see that callMath.rex is not entered. The program itself is simple: return rxcalcsqrt(4) In the INVOCATIONTester.cls when it gets to callMath.rex, I see the subject line print in the shell: ... programName: /work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/initialAddress.rex programName: /work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/initialAddress.rex programName: /work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/callMath.rex terminate called after throwing an instance of 'ActivityException' programName: /work.ooRexx/ooTest/4.0.0/ooRexx/API/oo/tests/callPath.rex ... Since I can't find that string, (or even the string 'called after throwing',) anywhere in the test suite files or in the interpreter source files, I think it might be coming from the C++ runtime. Anyone have any ideas on what to look for to debug it? The test passes on Windows and I haven't tried on any other Linux versions. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 5:24 PM, Rick McGuire wrote: > Yes, I was just looking at the same code you were...this is all > screwed up. I'm not really sure how anything is working! I believe > that second nestAttach() in the attachThread() code is wrong, but the > size of the comment there tells me I added that for a reason. > However, the only place where the nesting check is performed in is in > the DetachThread() code, which means a DetachThread() operation is > essentially a NOP, so I don't understand why we don't see more hangs. > I recommend removing that nestAttach() call and see if it clears > things up. We need to make sure we run the entire test suite before > checking that fix in though! Well the change certainly fixes things for me. I'll run the test suite and more before I check it in. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 5:18 PM, Mark Miesfeld wrote:
> On Sat, Jan 23, 2010 at 5:06 PM, Rick McGuire wrote:
>
>> H, this probably requires some tracking on the AttachThread() call
>> to figure out why this is created as a nested attach.
>
> That's what I was doing all morning until I had myself
> throughly confused and decided I needed some help from you.
With this change, the hang goes away:
C:\work.ooRexx\wc\main>svn diff interpreter
Index: interpreter/runtime/InterpreterInstance.cpp
===
--- interpreter/runtime/InterpreterInstance.cpp (revision 5502)
+++ interpreter/runtime/InterpreterInstance.cpp (working copy)
@@ -206,9 +206,7 @@
// we need to get a new activity set up for this particular thread
activity = ActivityManager::attachThread();
-// this is still attached, but we'll release it once it is
detached. We start with
-// a count of 1 and cleanup once we hit zero.
-activity->nestAttach();
+
// resource lock must come AFTER we attach the thread, otherwise
// we can create a deadlock situation when we attempt to get the kernel
// lock
@@ -258,7 +256,7 @@
ActivityManager::returnActivity(activity);
// Was this the last detach of an thread? Signal the shutdown event
-if (allActivities->items() == 0 && terminating)
+if (allActivities->items() <= 1 && terminating)
{
terminationSem.post();
}
C:\work.ooRexx\wc\main>
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 5:06 PM, Rick McGuire wrote:
> H, this probably requires some tracking on the AttachThread() call
> to figure out why this is created as a nested attach.
That's what I was doing all morning until I had myself
throughly confused and decided I needed some help from you.
In this section, activity comes back NULL, but then it does a
nestAttach() anyway.
// first check for an existing activity
RexxActivity *activity = findActivity();
// do we have this? we can just return it
if (activity != OREF_NULL)
{
// make sure we mark this as attached...we might be nested and
don't want to
// clean this up until we complete
activity->nestAttach();
return activity;
}
// we need to get a new activity set up for this particular thread
activity = ActivityManager::attachThread();
// this is still attached, but we'll release it once it is
detached. We start with
// a count of 1 and cleanup once we hit zero.
activity->nestAttach();
What I did was comment out the last activity->nestAttach() and then
change the other test to allActivities->items() <= 1 and the hang went
away. But, I wasn't / am not sure if that last nestAttach() needs to
be there because of the comment.
--
Mark Miesfeld
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 4:29 PM, Rick McGuire wrote:
> Mark, looking through other parts of the code that post the
> terminationSem, the test is for allActivities->items() <= 1, not == 0.
> You might want to try that change to see if it makes your hang go
> away.
Okay. But what I see in
InterpreterInstance::detachThread(RexxActivity *activity) is that on
this test:
if (activity->isNestedAttach())
{
// if we reused the activity because of a nested callback attach, then
// we just decrement the nesting count and return without cleaning up
// any resources.
activity->returnAttach();
return true;
}
isNestedAttach() is true, so it returns and does not get to this code.
// Was this the last detach of an thread? Signal the shutdown event
if (allActivities->items() == 0 && terminating)
{
terminationSem.post();
}
--
Mark Miesfeld
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 4:07 PM, Rick McGuire wrote: > On Sat, Jan 23, 2010 at 7:05 PM, Mark Miesfeld wrote: >> >> Okay. I'm on 64-bit XP. I don't see how that would make a >> difference. I'll do some more investigation. >> >> So what you see is something like: >> >> In Rexx method ONDTPCLOSEUP. Thread ID: 436 >> >> Leaving Rexx method ONDTPCLOSEUP. Thread ID: 436 >> In Rexx method OK. Thread ID: 4464 >> Leaving Rexx method OK. Thread ID: 4464 > > Yep, that's exactly what I see. Okay Rick, thanks for taking a look at it. I'll have to figure out why it is behaving differently for me. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 3:57 PM, Rick McGuire wrote: > Still not seeing a hang. I get same sequence of messages. There is a > very long delay between the first message and the second (I suspect > that's the loop), then I see the rest of the sequence and the program > exits. Okay. I'm on 64-bit XP. I don't see how that would make a difference. I'll do some more investigation. So what you see is something like: In Rexx method ONDTPCLOSEUP. Thread ID: 436 Leaving Rexx method ONDTPCLOSEUP. Thread ID: 436 In Rexx method OK. Thread ID: 4464 Leaving Rexx method OK.Thread ID: 4464 What I see is more like: In Rexx method ONDTPCLOSEUP. Thread ID: 436 In Rexx method OK. Thread ID: 4464 Leaving Rexx method OK.Thread ID: 4464 Leaving Rexx method ONDTPCLOSEUP. Thread ID: 436 -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 3:45 PM, Rick McGuire wrote: > The order of operations also does not appear to be the same as what > you're seeing. Here's the trace entries I'm seeing: > > In Rexx method ONDTPCLOSEUP. Thread ID: 436 > Leaving Rexx method ONDTPCLOSEUP. Thread ID: 436 > In Rexx method OK. Thread ID: 4464 > Leaving Rexx method OK. Thread ID: 4464 > Leaving Rexx main program Thread ID: 4464 I think you need to click twice, quicker on the OK button. It will only hang if leaving ONDTPCLOSEUP happens after leaving Rexx main program. Or in the example program up the loop count (and click twice quicker.) ::method onDTPCloseUp unguarded say 'In Rexx method ONDTPCLOSEUP. Thread ID:' .DlgUtil~test(0) do 10 y = 7 + 7 + 7 y = y / 7 y = 7 * 7 y = 7 ** 1000 end Change the do 10 to a higher number, like do 40 or maybe just add a 0 to make it 100. It could be that your system is faster than what I'm on right now. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Still having problems with DetachThread() / ooDialog
On Sat, Jan 23, 2010 at 3:08 PM, Rick McGuire wrote: > I suspect I'd need to look at the threads in the debugger to get an > idea on what is causing the hang. Okay, I need to commit my current ooDialog code so the example program will run. I'll then open a bug report and attach the program. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Still having problems with DetachThread() / ooDialog
Hi Rick, Do you have any insight on this problem? I have a thread context pointer to directly invoke the Rexx method in a Rexx dialog from the Windows dialog procedure thread. If the invoked Rexx method is still active when the user closes the dialog and the main portion of the program ends, the interpreter never terminates. The termination semaphore is never posted, even though the invoked Rexx method finishes and DetachThread() completes. It seems to me, when the invoked Rexx method finishes and DetachThread() is called, then the interpreter should terminate. I realize you probably need an example program, but here's some debug print out from the program. Maybe this is enough: C:\hang.on.terminate>userTestDT.rex Matched WM_NOTIFY going to invoke ONDTPCLOSEUP threadID=2992 In Rexx method ONDTPCLOSEUP. Thread ID: 2992 Matched WM_COMMAND going to queue OK threadID=2992 In Rexx method OK. Thread ID: 496 Leaving Rexx method OK.Thread ID: 496 delDialog() hDlg=001503A2 Going to DestroyWindow(dlg) Leaving Rexx main program Thread ID: 496 Leaving Rexx method ONDTPCLOSEUP. Thread ID: 2992 Dropped out of message loop, WindowUsrLoopThread threadID=2992 Going to call DetachThread, WindowUsrLoopThread threadID=2992 InterpreterInstance::detachThread() activity=075F6830 isAttached=1 isActive=0 isNested=1 InterpreterInstance::detachThread() allActivites items=2 terminating=1 Leaving WindowUsrLoopThread threadID=2992 At this point, things are hung. You need to use taskmanager to kill the rexx process. If it's not enough, then I need to commit some ooDialog code. Then I could either send you the example program, or open a bug and attach the program. Whatever is easier for you. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Some questions on C++ API DetachThread()
On Fri, Jan 22, 2010 at 1:40 PM, Rick McGuire wrote: > On Fri, Jan 22, 2010 at 4:25 PM, Mark Miesfeld wrote: >> In thread 2, it is guaranteed that the SendMessage() is invoked before >> any DetachThread() is done. But, it is not guaranteed that it has >> returned from myMethod(). Is that going to cause problems? When, it >> does return, dlgProcContext will not be used again. > > That will not work. DetachThread() can only be called for a thread > context that a) was obtained via AttachThread() and b) there is > nothing active on the thread. If there is an active method call, then > this cannot be used (which is why I don't really recommend trying to > do a detach from the same thread). Okay, thanks Rick. It makes sense the more I've been thinking about it. I found I had problems by putting a sleep in the method call and then closing the Windows dialog. Nothing crashed but the interpreter would not terminate properly. -- Mark Miesfeld -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Some questions on C++ API DetachThread()
I have a few questions on DetachThread.
Does DetachThread() need to be run on the same thread as
AttachThread()? Or, if you have the RexxThreadContext pointer, can
you invoke DetachThread() from a different thread? I've been assuming
you could invoke DetachThread() from some other, second thread.
My second question is dependent on the answer to the first question.
Assuming you can invoke DetachThread() from a second thread, what
happens if you do a DetachThread() in a second thread after a Rexx
method has been started on the thread context, but hasn't returned?
Something like:
thread 1 (same thread as thread context was obtained through
AttachThread. dlgProcContext is the thread context pointer.)
RexxObjectPtr result = pcpbd->dlgProcContext)->SendMessage(myObj,
"MYMETHOD", args);
thread 2
if ( pcpbd->dlgProcContext != NULL )
{
pcpbd->dlgProcContext->DetachThread();
pcpbd->dlgProcContext = NULL;
}
In thread 2, it is guaranteed that the SendMessage() is invoked before
any DetachThread() is done. But, it is not guaranteed that it has
returned from myMethod(). Is that going to cause problems? When, it
does return, dlgProcContext will not be used again.
--
Mark Miesfeld
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Opinions Wanted
On Sat, Jan 9, 2010 at 9:43 AM, David Ashley wrote: > I am working on an ooRexx interface to something that is normally > programmed in C. Of course, C uses zero-based indexes for thing like > memory, array positions, etc. My code could be architected to either > carry this forward to the ooRexx interface when it calls the C functions > or it could translate the zero-based numbers to the more user friendly > (and Rexx default) one-based numbering system. This is a good topic and one I have thought about, but I am also of two minds here. In ooDialog, it looks to me that they started out converting the zero-based indexes to one-based, but then did not carry through with that consistently with later code. Some of the earliest basic controls, (combo box, edit, etc.) convert the underlying 0-based indexes to 1-based indexes. Then 'newer' controls (list-view, etc.,) retain the underlying 0-based indexes. That of course is the worst possible approach. Obviously you would want one package to be consistent through out. So, I've thought about, if I could redo the entire package, would it be best to retain the underlying 0-based indexes, or use 1-based indexes through out. The main con to using 1-based indexes for ooDialog, as I see it, is that the MSDN documentation is so much more complete. There is no way that the ooDialog documentation can reproduce all that. So, it would be ideal, I think, for the ooDialog doc to say this is a brief overview, the ultimate documentation is MSDN. Especially with Google and other search tools, it would be much easier for ooDialog programmers to figure out how to use the dialogs and dialog controls from doc and examples on the Internet. Which of course will always use 0-based indexes. The pro of course is that Rexx uses 1-based indexes, so converting the indexes would make things more consistent with Rexx itself. Another problem with converting to 1-based indexes, (which comes back to documentation) in ooDialog is how to be consistent with special values. Often a index of -1 indicates an error, but sometimes not. Do you convert -1 to 0? Do you leave it at -1? There are places where it is hard to be completely consistent, because the Windows API is not always consistent. But, the MSDN documentation, usually documents what is what with respect to indexes. So, in the this area, it would nice to be able to say, whatever MSDN says is correct. You can't do that if you are converting indexes. All in all, I'm not sure which would be best. But, for external packages that provide a way to access and use a well known API, such as the Win32 API, I'm learning towards it would be better to be able to say the well known documentation on the API is the authority. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] C++ API Question
On Thu, Jan 7, 2010 at 4:11 PM, David Ashley wrote: > Rick/Mark - > > I have come across a problem using the new C++ API. I have a buffer of > data that I want to return from a method as a RexxString. The problem is > that this buffer may contain embedded nulls, thus none of the > String/CSTRING methods will work for the conversion. Is there a way to > do this? One form of the NewString() takes a length argument. That should do the trick. Page 198 in rexxprg.pdf -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Using the addcheckbox method
On Mon, Jan 4, 2010 at 1:05 PM, Mark Miesfeld wrote: > On Mon, Jan 4, 2010 at 12:51 PM, David Ruggles wrote: > >> Ok, thank you. That is what I did and it works. However, the next question I >> have is can I have it do something when the check box is changed without >> having to click a button? > Your dialog has to inherit AdvancedControls It also needs to inherit MessageExtensions. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Using the addcheckbox method
On Mon, Jan 4, 2010 at 12:51 PM, David Ruggles wrote: > Ok, thank you. That is what I did and it works. However, the next question I > have is can I have it do something when the check box is changed without > having to click a button? Sure, connect the check box event to a method in your dialog and when the method is invoked, do what you want. Something like this: ::method defineDialog ... self~connectButtonNotify(10, "CLICKED", onCheckBoxClick) ... ::method onCheckBoxClick chk = self~getCheckControl(10) if chk~isChecked == "CHECKED" then do -- The click on the button checked it, -- do what you want end else do -- The click just unchecked the button, -- do what you want. end ... Your dialog has to inherit AdvancedControls -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Using the addcheckbox method
On Mon, Jan 4, 2010 at 12:29 PM, David Ruggles wrote: > according to the documentation, if you leave the second argument blank it > should be data || id so in this case data10 which is what was confusing me. Unfortunately, there are many spots in the ooDialog that are either incomplete, misleading, or wrong. It was the way the doc was that we inherited. In the case of a check box control, if you leave the attribute blank, I believe it creates the attribute from the label of the button: ERRORMESSAGES should be the attribute name. If the label is omitted, then I think it uses DATA10. It is actually rather difficult to predict what the attribute name is going to be; you're probably better off naming it explicitly in your code. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hostemu
On Tue, Dec 29, 2009 at 2:35 AM, Jean-Louis Faucher wrote: > It works for me, with a fresh rebuild of ooRexx. > > This script displays 81 when run from hostemu directory : > > address hostemu 'execio * diskr "readme.txt" (finis stem in.' > say in.0 > ::requires "hostemu" LIBRARY David, I had a little extra time today. It seems to work fine for me too. I ran a couple variations on the above, including the hostemu.cls program, and they all worked fine. For example: say 'Starting' address hostemu 'execio * diskr "./hostemu.def" (finis stem in.' do i = 1 to in.0 say in.i end return ::requires "hostemu" LIBRARY Gives: C:\work.ooRexx\wc\incubator\hostemu>testHostEmu.rex HOSTEMU: Library loaded. HOSTEMU: RexxRegisterSubcomExe retc = 0. HOSTEMU: CreateMutex htmxExecIO = 236. Starting HOSTEMU: Subcom called. HOSTEMU: Parse complete. HOSTEMU: Executing execio statement. HOSTEMU: Subcom return code = 0. ;/**/ ;/* */ ;/* Copyright (c) 2009-2010 Rexx Language Association. All rights reserved.*/ ;/* */ ;/* This program and the accompanying materials are made available under */ ;/* the terms of the Common Public License v1.0 which accompanies this */ ;/* distribution. A copy is also available at the following address: */ ;/* http:;;www.oorexx.org/license.html */ ;/* */ ;/* Redistribution and use in source and binary forms, with or */ ;/* without modification, are permitted provided that the following */ ;/* conditions are met: */ ;/* */ ;/* Redistributions of source code must retain the above copyright */ ;/* notice, this list of conditions and the following disclaimer. */ ;/* Redistributions in binary form must reproduce the above copyright */ ;/* notice, this list of conditions and the following disclaimer in */ ;/* the documentation and/or other materials provided with the distribution. */ ;/* */ ;/* Neither the name of Rexx Language Association nor the names */ ;/* of its contributors may be used to endorse or promote products */ ;/* derived from this software without specific prior written permission. */ ;/* */ ;/* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS*/ ;/* AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT */ ;/* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS */ ;/* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT */ ;/* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, */ ;/* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED */ ;/* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,*/ ;/* OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY */ ;/* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING*/ ;/* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS */ ;/* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ ;/* */ ;/**/ EXPORTS RexxGetPackage C:\work.ooRexx\wc\incubator\hostemu> -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Hostemu
On Mon, Dec 28, 2009 at 5:46 PM, David Ashley wrote: > I tried to create a Windows version of Hostemu in the incubator. But I > get a seg fault when I run it. It dies when the Rexx runtime tries to > call the GrxHost routine. Would you mind seeing what you can do with > this to make it work under Windows? My Windows debugging skills have > just disappeared over the years. > > I know the the package loader routine gets called and the > RexxRegisterSubcom function and the CreateMutex functions both succeed. > There is a printf at the top of the GrxHost function that never get > invoked. This makes ne think that there is some kind of linking problem > with GrxHost that is not showing up until run time. David, I'll take a look at it. Probably have to be after Wednesday though. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] ooDialog will not compile right now
All, I just noticed that I committed some code in ooDialog that won't compile. Must have been sleepy. I'll have to fix it tonight, just thought I'd let people know. If by chance someone is reading the dev list and absolutely needs to compile on Windows before tonight - here is the change: extensions\platform\windows\oodialog\oodBaseDialog.cpp around line 1014, remove these lines: -RexxMethodContext *c = context; -c->ObjectToUnsignedInt32() - extensions/platform/windows/oodialog/oodBarControls.cpp around line 128, add a semi-colon: -max = 100 + max = 100; -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Incubator Status
On Mon, Dec 21, 2009 at 7:32 AM, David Ashley wrote: > I had a chance to look at the incubator over the weekend. There is a lot > of good stuff just sitting there going nowhere. I would like to take on > the task of moving some of that stuff into the main trunk. It will > involve some work as there is missing documentation and tests that need > to be created for some of those projects. > > What I need to know is are there objections or projects that are not > really ready yet. David, I just looked over my local copy of the incubator. None of my stuff is really ready, but there is some clean up that can be done. ooRexxTry -> this was already moved, but it looks like the top level directory is still there. That directory can be removed. WinShell -> that is an old version created before the C++ APIs. It can be removed. You could remove them, otherwise I'll delete them the next time I have a good svn connection. WinShell.4.0.0 still needs some work. And, the other stuff I have is in the samples directory. I intend to move those / some of those into the distribution, but I still need to do some work with them. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] oodialog : questions about syntax diagrams
On Sat, Dec 19, 2009 at 3:42 PM, Mark Miesfeld wrote: > the argument is required, it close on the same line as the method Another typo, should read: it goes on the same line as the method -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] oodialog : questions about syntax diagrams
On Sat, Dec 19, 2009 at 2:08 PM, Jean-Louis Faucher wrote: > In oodialog/userdialog.sgml, I have several syntax diagrams which are > currently not supported by the parser. > It's a problem of opening/closing "+" > > For example, see addGroupBox (copy/paste in a text editor for good > alignment). > Currently, we have : > --+-+---++-- > +-,-text--+-,--style--+-,--id--+ Jean-Louis, this is just a typo, or copy and paste error, or whatever you want to call it.It wasn't done on purpose, so sure go ahead and fixe it, add the closing + > Other question, in oodialog/utilityclasses.sgml, this diagram is not > supported, and I don't know how to interpret it. > See line 2121 for aDlgAreaU~Init >>>- aDlgAreaU~Init(Dialog--+--++-)-->< > +--,--Margin-+ | | > +--,-+--,-NoResize-+ | > +--,-+--,--+-NoMove-+ I'm using what I call "simplified" railroad tracks in ooDialog. I'm changing them as I work on sections so that they only use 2 lines. If the argument is required, it close on the same line as the method name. If the argument is optional, it goes on the second line. The text explains the arguments. So I just changed that diagram and committed it. To this: >>-init(-dlg--+--+--++--++-)-->< +-,-margin-+ +-,-noResize-+ +-noMove-+ (of course the + all line up properly.) Feel free to change any syntax diagrams if you need to. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx:[5437] rexxgtk/trunk/grxtreestore.cpp
David, I don't have GTK installed here so I can't check for sure. But, in the following: unsigned int uival; ... case G_TYPE_UINT: case G_TYPE_ULONG: context->ObjectToStringSize(context->ArrayAt(args, i + 1), (size_t *)&uival); coldata.data[0].v_uint = uival; break; case G_TYPE_INT64: context->ObjectToInt64(context->ArrayAt(args, i + 1), &ival64); coldata.data[0].v_int64 = ival64; break; case G_TYPE_UINT64: context->ObjectToUnsignedInt64(context->ArrayAt(args, i + 1), &uival64); coldata.data[0].v_uint64 = uival64; break; It looks to me like GTK is defining their own G_TYPE_xxx names to have portable code. If so, I think you should have used this to fix the compile problem on 64-bit Ubuntu: context->ObjectToUnsignedInt32(context->ArrayAt(args, i + 1), &uival); not this: context->ObjectToStringSize(context->ArrayAt(args, i + 1), (size_t *)&uival); In the above, on 64-bit systems, your casting the address of a 32-bit variable to the address of a 64-bit variable. That seems likely to cause problems. On the other hand, if GTK is varying the size of: G_TYPE_ULONG depending on the operating system, then maybe you should change the declaration of uival from: unsigned int uival; to: G_TYPE_ULONG uival; -- Forwarded message -- From: Date: Fri, Dec 18, 2009 at 8:08 AM Subject: [Oorexx-svn] SF.net SVN: oorexx:[5437] rexxgtk/trunk/grxtreestore.cpp To: oorexx-...@lists.sourceforge.net Revision: 5437 http://oorexx.svn.sourceforge.net/oorexx/?rev=5437&view=rev Author: wdashley Date: 2009-12-18 16:08:47 + (Fri, 18 Dec 2009) Log Message: --- Oops! Left out the astericks! Modified Paths: -- rexxgtk/trunk/grxtreestore.cpp Modified: rexxgtk/trunk/grxtreestore.cpp === --- rexxgtk/trunk/grxtreestore.cpp 2009-12-18 14:45:08 UTC (rev 5436) +++ rexxgtk/trunk/grxtreestore.cpp 2009-12-18 16:08:47 UTC (rev 5437) @@ -177,7 +177,7 @@ break; case G_TYPE_UINT: case G_TYPE_ULONG: - context->ObjectToStringSize(context->ArrayAt(args, i + 1), (size_t)&uival); + context->ObjectToStringSize(context->ArrayAt(args, i + 1), (size_t *)&uival); coldata.data[0].v_uint = uival; break; case G_TYPE_INT64: This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-svn mailing list oorexx-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-svn -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Proposition : would like to fix the doc for parsing the syntax diagrams
On Tue, Dec 15, 2009 at 11:49 PM, Jean-Louis Faucher wrote: > Assuming that the syntax diagrams will not be replaced soon by something > else (let me know :-), I'd like to apply the fixes described in the attached > file. > Those fixes are 100% compatible with the current toolset. Jean-Louis, if there is no impact on the current doc build, I don't have any problem with you making the changes. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] New Win Build Problem
On Tue, Dec 15, 2009 at 7:22 PM, David Ashley wrote: > Got a new problem. During the NSIS build I get a message that says > > Invalid command: services::IsServiceRunning > Error in script "oorexx.nsi" on line 669. > > I think this has to do with one of the plugins but I am not for sure. Yes, it does come from a plugin being missing. You need services.dll in the Pluging directory of the NSIS install. Plus KillProc.dll and FindProcDLL.dll Directory of C:\Tools\misc.dev.tools\Nsis\Plugins 02/12/2009 09:26 AM . 02/12/2009 09:26 AM .. 01/15/2007 03:21 PM 3,584 FindProcDLL.dll 01/15/2007 05:48 PM 4,096 KillProcDLL.dll 09/08/2003 02:19 AM 7,680 services.dll The Plugins directory has other plugins, I just list those three. On SourceForge in the download area is: windows-build-tools version 1.0 It has the following file for download: nsis_plugins_unzip_in_plugin_directory.zip That file has the needed plugins if you can't find them on the system. That should solve the problem. -- Mark Miesfeld -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Help! The Win build vaitual machine is broken again
On Mon, Dec 14, 2009 at 6:22 PM, David Ashley wrote: > Mark - > > I discovered that the C++ compiler that I was using in the Win build VM > was really old. So I uninstalled it and installed Visual C++ v8 and the > Windows SDK. Only NMAKE seems to be missing! > > I went back and looked at the Windows build instructions and nothing I > have tried seems to fix the build. Could you please update those > instructions so I can get the Win build back up? Sure David. Did you install the Express edition? (I would imagine so.) nMake shouldn't be missing, rather I think the environment is not getting set correctly. You need to edit the registry. Later editions of the Windows SDK and VC++ use delayed environment variable expansion. But that feature is turned off by default. Using regedit, edit the following REG_DWORD value in the registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\DelayedExpansion set it to 0x1 If the DelayedExpansion value is not already there then just add it. That should solve the problem. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] New *nix external function library
On Mon, Dec 14, 2009 at 8:35 AM, Rick McGuire wrote: > Sigh, Sigh ? give a guy a break.No one ever told me the original purpose of RexxUtil. > the original purpose of RexxUtil was to hold functions that were > system specific and not necessarily portable. Okay, I withdraw my objection. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] New *nix external function library
On Mon, Dec 14, 2009 at 8:11 AM, David Ashley wrote: > I just added the nixclib external function library to the ooRexx > incubator. These are external functions that access some very useful > *nix APIs. Please take a look and let me know what you think. I would be > happy to add any functions you think should be included. David, That sounds good and I'm all for it, in general. I do have one misgiving, objection. I would really like to see the functions in RexxUtil restricted to functions that are available on all platforms. Some day I intend / would like to work on making the functions that are Windows only in RexxUtil available on Linux / Unix platforms. I really wish that functions like the WinPrinter stuff, that can't be cross platform, had been put into the WinSystem function library, but it is too late for that. I would really prefer to not add any new functions to RexxUtil unless they are cross platform. Is there the possibility that the functions you are working on that are Unix only be put in a package similar to WinSystem and added to the distribution? -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx Build machine Status
On Sun, Dec 13, 2009 at 3:37 PM, David Ashley wrote: > The build machine is now completely back up with the exception of a > Debian/Ubuntu build. I will work on that this next week. Thanks for all the hard work David. > > ---> BTW. The Win build currently has a syntax error. Hmm, I'll take a look at that. I don't get any errors on any of the Windows systems I build on. > C:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7\PlatformSDK\Include\NewAPIs.h(325) That seems as though something is not set to only build for W2K or later. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] SysFileTree under win32 : beware to short file names !
On Sun, Dec 13, 2009 at 2:07 PM, Jean-Louis Faucher wrote: > yes, exactly... > We have no bug here, it's an odd behavior of win32 api > See attached file, unzip and run the rex script from the folder. Thanks Rick / Jean-Louis. Jean-Louis, It seems like it is a bug here, f.odga does not match *.odg. I still think you should open a bug. I'll take a look at fixing it some time in the future, or someone else will. If we decide after investigation it isn't a bug - we can always close it. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] SysFileTree under win32 : beware to short file names !
On Sun, Dec 13, 2009 at 1:39 PM, Jean-Louis Faucher wrote: > Maybe this is already a known problem by the group, but I was unaware of > that till today... > > Under win32 (and probably win64), call SysFileTree "*.odg", "files", "FO" > will return all the following files : > f.odga > f.odg1 > .~lock.dlgArea.odg# I'm probably a little dense on this Jean-Louis, but could you explain this a little. What are all the actual file names in the directory and what exactly is returned in the stem? Are you saying it returns two file names for the same file, or ... ? Or, you could open a bug with a test case. Include all the actual files in the zip file for the test case and exaplain what is wrong with the output of the test case. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A proposition for better image quality in PDF documentation
On Tue, Dec 8, 2009 at 10:59 AM, Rick McGuire wrote: > On Tue, Dec 8, 2009 at 1:51 PM, Jean-Louis Faucher > wrote: >> I propose to do the changes on rxsock, and test the result with the build >> machine. >> Then I will apply the changes to the rest of the documentation, if it works. I'm fine with all this Jean-Louis. As Rick said, commit the changes to trunk. If they don't work out, you can just back the changes out. >> Q3 >> The following .jpg images should be also replaced by .pdf images : >> oodialog : dlgarea.jpg (p423), dlgareaplan.jpg (p428), rxou0s12.jpg (p6), >> rxou0s24.jpg (p6) >> rexxpg : rxoq0s05.jpg (p62), rxoq0s06.jpg (p64), rxoq0s07.jpg (p79), >> rxoq0s09.jpg (p80) >> Do you have the source files of these images ? Jon produced the dlgarea and dlgareaplan files and the sample1.jpg, I imagine. He can probably produce the source. I'll take a look at the rx* files, maybe next week. We don't have the source, but I believe they were made as snapshots of example dialogs. I created a dialog to match one of the jpg files (rxou0s20.jpg) and I can do the same for the others. Then it is just a matter of executing the program and taking a snapshot picture of it in what ever format you need. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A proposition for better image quality in PDF documentation
On Tue, Dec 8, 2009 at 8:19 AM, Jean-Louis Faucher wrote: > This proposition has no impact on the HTML documentation. > ... > But if the > group is interested, I can investigate to verify if the toolset supports > this format. I'm definitely interested in better images for the PDF doc. I've noticed blurry images several time. Just not interested enough to spend any time on it. If it doesn't have any adverse impact on anything else, sounds good to me. -- Mark Miesfeld -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Mod_Rexx 2.0 - help/input for a seminarpaperneeded
On Sun, Nov 29, 2009 at 12:50 PM, Robert Maschek wrote: >> Mark Miesfeld wrote: >> >> Note that it is very easy to get your own Windows version built from >> SVN trunk. Simply go to: >> >> http://build.oorexx.org/build.html > I tried this today but it seems that there's a server problem. > At least I got an "Internal Server Error" I believe that David is doing some maintentance on the build server, so you just picked a bad time. Things should be working next week. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Discuss: Should we do a bug fix update?
On Fri, Nov 13, 2009 at 12:09 PM, David Ashley wrote: > I don't think we should be in quite that bit of a hurry. I am ok with > trying to get something out by the end of the year so as not to push us > too much. Okay David. I'm not so much in a hurry, I just wanted to discuss it. I do think doing more frequent bug-fix releases is beneficial to the users. The first part of January is a good time to take a look at doing it. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Discuss: Should we do a bug fix update?
On Fri, Nov 13, 2009 at 9:20 AM, Rick McGuire wrote: > I'm not adverse to doing a bug fix release, but the appropriate way to > do this would be to copy the 4.0.0 release into a 4.0.1 branch and > merge any bug fixes back into that branch. I know for my changes, the > trunk code base is not really in releasable shape, and will not be > there for some time. Most of the bug fixes should merged back into > 4.0.0 fairly cleanly. There have been a enough other bugs reported > against the base interpreter to warrant a point release. Okay, well yeah, that's the right way to do it. I wasn't thinking so much of the how as to 'should we.' You're right of course, trunk is not in a releasable state. If David is agreeable, we can figure out a schedule. I should have some free time Thanksgiving week. I'll do most of the work if David is busy. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Discuss: Should we do a bug fix update?
All, I would not be adverse to doing a bug fix release sometime between now and the new year. Wondering what others think? For myself, I still have quite a bit to do to convert all the old-style external functions in ooDialog to the C++ API. I won't have that done for some time. So, what I was thinking of doing is temporarily swapping out the current ooDialog code with the 4.0.0 release code and merge in the ooDialog bug fixes reported by others to date. Then going with that for the bug fix release. I'm not driven to do a bug fix release, but it seems reasonable to me to not make some of the users that have reported bug wait, until I have the ooDialog stuff where I want it for a next release. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx Build Machine Upgrade
Shouldn't bother me David. Thanks for the update. -- Mark Miesfeld On Tue, Nov 10, 2009 at 5:25 PM, David Ashley wrote: > All - > > During the week of Thanksgiving here in the US (week of Nov 23) I am > planning to upgrade the Build Machine to the latest version of Fedora > 12. Fedora 12 should GA on Nov 17 and if it does then I will upgrade the > server, if not then I will delay until the Christmas holidays. > > Obviously the server will be off-line during this time. Will this impact > anyone adversely? If so please let me know. > > Thanks, > David Ashley > ooRexx Build Team > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile ooRexx for Windows using latest rev. 5307
Rony, The problem with the PATH is because the new SDK's use delayed environment variable expansion. This is disabled by default in older operating systems like XP, and as you've seen, it results in the path being wiped out. Not sure why the Microsoft developers do that. It could be that they too want to move forward, not live in the past. I've found that the simplest thing to do is to enable it in the registry. You can get this info by doing: cmd /? at the command line. Delayed environment variable expansion is NOT enabled by default. You can enable or disable delayed environment variable expansion for a particular invocation of CMD.EXE with the /V:ON or /V:OFF switch. You can enable or disable completion for all invocations of CMD.EXE on a machine and/or user logon session by setting either or both of the following REG_DWORD values in the registry using REGEDT32.EXE: HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\DelayedExpansion and/or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\DelayedExpansion to either 0x1 or 0x0. The user specific setting takes precedence over the machine setting. The command line switches take precedence over the registry settings. If delayed environment variable expansion is enabled, then the exclamation character can be used to substitute the value of an environment variable at execution time. Have fun. -- Mark Miesfeld _ From: Rony G. Flatscher [mailto:rony.flatsc...@wu-wien.ac.at] Sent: Saturday, November 07, 2009 1:23 PM To: Open Object Rexx Developer Mailing List Subject: Re: [Oorexx-devel] Cannot compile ooRexx for Windows using latest rev. 5307 Mark Miesfeld wrote: On Sat, Nov 7, 2009 at 8:16 AM, Mark Miesfeld <mailto:miesf...@gmail.com> wrote: On Sat, Nov 7, 2009 at 8:03 AM, Rony G. Flatscher <mailto:rony.flatsc...@wu-wien.ac.at> wrote: Just went to <http://msdn.microsoft.com/en-us/windows/bb980924.aspx> <http://msdn.microsoft.com/en-us/windows/bb980924.aspx> which offers a SDK supporitng Windows 7 (dated August 2009) and one supporting Windows Server 2008 (dated February 2008). Is using the Windows 7 SDK o.k.? That should be fine, I think. I just committed a change so that trunk will compile with older versions of the SDK. A problem with moving to the Windows 7 SDK could be this: I haven't compiled with that late of a SDK, yet, so I can't guarantee that you won't run into some other compile error. With each new SDK, Microsoft will / may drop some support for older features. There is always the chance that the newest SDK may drop something being used in the current code base. There is still stuff in the Windows code that was for Windows 3.1. Thank you very much for your efforts! In the meantime I have downloaded the Win7 SDK version and installed it. Using it to set the environment seems to wipe out the current PATH value; didn't have time to look into this further. Correcting the PATH by hand and then compiling ooRexx did work, so there should be no incompatibilities be introduced by it. In the meantime I will drop back to the Server 2003 SDK script thanks to your efforts, which are highly appreciated! ---rony -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile ooRexx for Windows using latest rev. 5307
On Sat, Nov 7, 2009 at 8:16 AM, Mark Miesfeld wrote: > On Sat, Nov 7, 2009 at 8:03 AM, Rony G. Flatscher > wrote: >> Just went to <http://msdn.microsoft.com/en-us/windows/bb980924.aspx> which >> offers a SDK supporitng Windows 7 (dated August 2009) and one supporting >> Windows Server 2008 (dated February 2008). Is using the Windows 7 SDK o.k.? > > That should be fine, I think. I just committed a change so that trunk will compile with older versions of the SDK. A problem with moving to the Windows 7 SDK could be this: I haven't compiled with that late of a SDK, yet, so I can't guarantee that you won't run into some other compile error. With each new SDK, Microsoft will / may drop some support for older features. There is always the chance that the newest SDK may drop something being used in the current code base. There is still stuff in the Windows code that was for Windows 3.1. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile ooRexx for Windows using latest rev. 5307
On Sat, Nov 7, 2009 at 8:03 AM, Rony G. Flatscher wrote: > Hmm, inferring from this it seems that my SDK is outdated? If so, that is > not a problem at all as I can update/install a new SDK. > > Just went to <http://msdn.microsoft.com/en-us/windows/bb980924.aspx> which > offers a SDK supporitng Windows 7 (dated August 2009) and one supporting > Windows Server 2008 (dated February 2008). Is using the Windows 7 SDK o.k.? That should be fine, I think. If you want to hold off on installing a new SDK, which does take a little time, I'd just substitute 0 for the WC_xxx constant to compile now. I just built on an old system of mine and get the same error, so I'll look closer at fixing the compile error. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Cannot compile ooRexx for Windows using latest rev. 5307
On Sat, Nov 7, 2009 at 2:33 AM, Rony G. Flatscher wrote: > trying to build ooRexx from trunk (rev. 5307) yields the following errors > and aborts the build process: > > rexxutil.cpp(5621) : error C2065: 'WC_ERR_INVALID_CHARS' : undeclared > identifier > rexxutil.cpp(5649): error C2065: 'WC_ERR_INVALID_CHARS' : undeclared > identifier > > This is using "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version > 15.00.21022.08 for 80x86" and the "SDK for Windows SErver 2003 R2". That looks like it comes from a change I made a while back. Jean Louis has analyzed it correctly. I'll look at it more closely this weekend. Ultimately though, I think I'm going to say that, since the Windows SDK is free, the solution is to upgrade your Windows SDK. The compiled binary runs fine on Windows XP and should, according to the docs, be fine on Windows 2K. Nevertheless, I'll look and see if there is a change that can be made. My goal is to move forward in time, not backwards. -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Mod_Rexx 2.0 - help/input for a seminarpaper needed
On Sun, Nov 1, 2009 at 1:12 PM, David Ashley wrote: > On 10/31/2009 04:30 PM, Robert Maschek wrote: >> I'm a student at the University of Economics in Vienna. For a seminar >> (with Prof. Rony Flatscher) in my specialisation "Management >> Information Systems" I have to write a seminarpaper about Mod_Rexx 2.0 >> and need your help. > > Second, I am working on Mod_ooRexx. This will be an Apache module for > ooRexx 4.0 or later only. It works for Linux but the same bug as above > causes it to crash under Windows. This code is in the ooRexx SVN > incubator currently. It is MUCH faster than the old Mod_Rexx code. Code > and RSP pages written for Mod_Rexx work unchanged in Mod_ooRexx. If you > want to work with this code you will need to build your own Windows > version of ooRexx from the SVN trunk. Note that it is very easy to get your own Windows version built from SVN trunk. Simply go to: http://build.oorexx.org/build.html Set the "system for the build" to Windows and the "build make target" to EXE. -- Mark Miesfeld > > Actually, I consider the documentation for Mod_Rexx and Mod_ooRexx to be > pretty good. But the weak are is examples. It needs a lot more of them > and they need to be practical and useful but small enough in size for > someone to comprehend easily. In fact, if your examples are good enough > I will consider adding them to the SVN repository and the distribution. > > As to resources, if you are getting into the nuts and bolts of the C > code then you should check out the book "The Apache Modules Book" by > Nick Kew (Prentice Hall). As to web resources, there is actually very > little out there other than what I have written on IBM developerWorks. > If you find something please pass it back to me. > > And I will be happy to answer any questions you might have about > Mod_Rexx and Mod_ooRexx. > > W. David Ashley > ooRexx Team > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] DocBook problems
On Thu, Oct 29, 2009 at 7:29 AM, David Ashley wrote: > This is a known problem when using DSSSL for the transform. It is fixed > when you use a pure XSL transform. Unfortunately you will just have to > experiment with your hyperlinks to find the one where the problem is. Thanks David. It's just tough to figure out where the offending hyperlink is. I guess I just need to compile often to catch a problem before I've made too many changes. -- Mark Miesfeld -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] DocBook problems
On Wed, Oct 28, 2009 at 7:57 AM, Mark Miesfeld wrote:
> It's the same problem I had quite awhile ago. The build process for
> oodialog.pdf ends with this:
>
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
> \pd
> fstartlink.
>
> \endgroup \...@typeset@protect
> l.185823 ... not used.\endSeq{}\endNode{}\endPar{}
> \endDisplayGroup{}\endNode...
>
> ! ==> Fatal error occurred, no output PDF file produced!
> Transcript written on oodialog.log.
> make[1]: *** [oodialog.pdf] Error 9
Well, in a follow up to myself. I browsed deeper in the Google
results and found this:
\pdfendlink ended up in different nesting level than \pdfstartlink
This happens when hyperref is used under pdftex and a citation splits
across a page boundary. To fix it, note the page number of the error
and specify the draft option to hyperref so you get an output PDF.
Then you can see the citation in question and rewrite to fix it.
(Thanks to James Bednar's posting on the pdftex list about this.)
So, that sounds promising, but I'm not sure how to use it. ;-(
David, can you help me with this?
1.) It says note the page number. ??? I don't see anything in the
output that I could translate to a page number.
2.) It says specify the draft option to hyperref. ??? I don't really
know what that means.
Or, 3.) do you think this is just a red herring?
--
Mark Miesfeld
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] DocBook problems
I'm having problems with DocBook, again, and thought I'd post here to
see if David, or anyone has any ideas.
It's the same problem I had quite awhile ago. The build process for
oodialog.pdf ends with this:
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\endgroup \...@typeset@protect
l.185823 ... not used.\endSeq{}\endNode{}\endPar{}
\endDisplayGroup{}\endNode...
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on oodialog.log.
make[1]: *** [oodialog.pdf] Error 9
You can see the full transcript at:
http://build.oorexx.org/builds/docs/5286/docs-buildrpt.txt
I'd googled it before and did so again yesterday. The "\pdfendlink
ended up in different nesting level than \pdfstartlink." is a reported
error that I could not find a solution for. From what I take on it,
it has something to do with page breaks occurring in the middle of
'something.'
The previous time this happened I fixed it by moving sections of text
around. Yesterday, I rolled back my commits until I got to a point
where the build would finish.
It is very hard for me to figure out where the error is happening, the
line numbers listed in the log don't seem to have any relationship to
the source code lines.
I was hoping that maybe David had run across a fix for this.
--
Mark Miesfeld
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A problem, uncovered under Linux, how to proceed ?
On Tue, Oct 13, 2009 at 8:03 AM, Rony G. Flatscher wrote: > (stting in a workshop) today I have been able to not only create a > 64-bit deb package, but also a 32-bit deb package for ooRexx from trunk, > rev. 5257. > > These versions are used to run the BSF4Rexx testsuite (as for the heavy > multithreading tests some post-release bugifxes in ooRexx are needed). > > Running the testsuite under those two Linux versions yields runtime > errors in the multithreading test groups. > > However, running some of those test groups individually (separately on > their own and not as part of a group of test groups) yields error-free runs! Rony, You might want to review this post: FYI test suite and low memory Linux systems sent on September 30th and see if that applies. If your test suite creates a lot of processes and your system does not have a lot of memory available, by today's standards, this could be the cause. This is especially likely on a Debian system, which by default does not install a high memory enabled kernel. The default Debian install will use a kernel image limited to around 800 megabytes, even if you have much more memory in your system. -- Mark Miesfeld -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] The .nil object and the Pointer class
On Mon, Oct 12, 2009 at 1:29 PM, David Ashley wrote: > The pointer class does not allow me to create a pointer instance from > Rexx code. You could do this, which is what I did in ooDialog, but Rick may not approve. In the very first init of ooDialog, in the C++ code I create a null .Pointer object and add it to the .local directory. Then in the Rexx code for ooDialog I can get a null .Pointer object from .local. I use the name NullHandle. So, .NullHandle in Rexx code gives me the argument I need to send to a native API method. -- Mark Miesfeld -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] make deb - problem: no "fakeroot" command ?
On Mon, Oct 12, 2009 at 1:20 PM, Mark Miesfeld wrote: > On Mon, Oct 12, 2009 at 1:07 PM, Rony G. Flatscher >> fakeroot dh_clean -k >> /bin/bash: fakeroot: command not found >> make: *** [deb] Error 127 >> >> A "sudo apt-get fakeroot" or "sudo apt-get fakeroot-ng" does not yield a >> package at all! > > Yeah, that's not the right package name. You need: Well, fakeroot is the name of the package. But you need the debhelper and other stuff listed the debian build file. Be sure you have those packages. If that still doesn't help, maybe you need to update what debian repostitories you are downloading from. I built, recently, on both 64-bit Debian and 64-bit Kubuntu. So things should work. -- Mark Miesfeld -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
