java package and MacOS

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
On Nov 27, 2012, at 10:23 PM, Michael Goffioul wrote:

> On Tue, Nov 27, 2012 at 10:18 PM, Ben Abbott <[hidden email]> wrote:
>
> On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:
>
> > On 11/27/2012 08:45 PM, Ben Abbott wrote:
> >>
> >> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
> > [snip]
> >>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
> >>>
> >>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
> >>>
> >>> Dan
> >>
> >> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
> >
> > Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
> >
> > I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
> >
> > Dan
>
> No.  The gui does not work yet on MacOS X.
>
> The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.
>
> The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>
> The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).
>
> There you obviously have a problem, you can't have Qt and Java running their own GUI loop in the main thread (at least not in a trivial way).
>
> Michael.

Maybe I was confused,  Does the Java gui loop run in the main thread?

Ben

Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Michael Goffioul
On Tue, Nov 27, 2012 at 10:31 PM, Ben Abbott <[hidden email]> wrote:
On Nov 27, 2012, at 10:23 PM, Michael Goffioul wrote:

> On Tue, Nov 27, 2012 at 10:18 PM, Ben Abbott <[hidden email]> wrote:
>
> On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:
>
> > On 11/27/2012 08:45 PM, Ben Abbott wrote:
> >>
> >> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
> > [snip]
> >>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
> >>>
> >>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
> >>>
> >>> Dan
> >>
> >> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
> >
> > Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
> >
> > I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
> >
> > Dan
>
> No.  The gui does not work yet on MacOS X.
>
> The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.
>
> The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>
> The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).
>
> There you obviously have a problem, you can't have Qt and Java running their own GUI loop in the main thread (at least not in a trivial way).
>
> Michael.

Maybe I was confused,  Does the Java gui loop run in the main thread?


It has to, under Mac OS X, but it doesn't from the octave java package. That's why GUI doesn't work from the octave java package under Mac OS X. Even if we find a way to make it work when running octave in CLI mode, it's not gonna work when running the Octave GUI, as the Qt event loop also has to run in the main thread. So you have a conflict between Qt and Java. There's probably a way to work around that issue, as there are (or has been) Java bindings for Qt, but I'm sure it's far from trivial.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Philip Nienhuis
In reply to this post by Carnë Draug-2
Carnë Draug-2 wrote
On 28 November 2012 02:58, Daniel J Sebald <[hidden email]> wrote:
> Regarding some of the functions in the java package and directing to the
> broader list, are the names "errordlg", "helpdlg", etc. language standards?
> If not, I wonder if their names should include "java" in some way.  The
> reason I wonder is because if one launches Octave with the new GUI/IDE then
> it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
> Java.  That way, it is the same look and feel and uses just one software
> exterior.
>
> I just tried creating some Java dialog boxes under the Octave IDE and it
> crashes on my system.  Should we start entering bugs for Java in the
> tracker, or wait a while?
They work all right on my Linux box even when invoked from the GUI.

But I see now that JWE has apparently transferred older versions of the dialog m-files into core Octave.

IIRC I have updated them last June and July for minor style changes and to accept multiline input for the MESSAGE argument (i.e., cellstr arrays). It also says so on the Java package page f. version 1.2.9, function details, on the OF website.

You are right, this things would look better as Qt widgets, and my
understanding is that these functions are going to be rewritten that
way. There's no reason for them to be limited to use java.
True.
But perhaps the Java-based dialog functions can still be present, yet shadowed by other (Qt? OpenGL?) versions. At least they do work now so these ML-compatible functions are now implemented.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Daniel Sebald
On 11/28/2012 01:41 PM, Philip Nienhuis wrote:

> Carnë Draug-2 wrote
>> On 28 November 2012 02:58, Daniel J Sebald&lt;
>
>> daniel.sebald@
>
>> &gt; wrote:
>>> Regarding some of the functions in the java package and directing to the
>>> broader list, are the names "errordlg", "helpdlg", etc. language
>>> standards?
>>> If not, I wonder if their names should include "java" in some way.  The
>>> reason I wonder is because if one launches Octave with the new GUI/IDE
>>> then
>>> it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
>>> Java.  That way, it is the same look and feel and uses just one software
>>> exterior.
>>>
>>> I just tried creating some Java dialog boxes under the Octave IDE and it
>>> crashes on my system.  Should we start entering bugs for Java in the
>>> tracker, or wait a while?
>
> They work all right on my Linux box even when invoked from the GUI.
>
> But I see now that JWE has apparently transferred older versions of the
> dialog m-files into core Octave.
>
> IIRC I have updated them last June and July for minor style changes and to
> accept multiline input for the MESSAGE argument (i.e., cellstr arrays). It
> also says so on the Java package page f. version 1.2.9, function details, on
> the OF website.

I tried the inputdlg() in octave-cli and that works with multiple lines.
  (It gives an arcane error about java.xyz something if the input format
is not a cellstr.  That should be changed to a meaningful error
statement conditioned in the script file.)

You're saying the versions of the java interactive elements now in
Octave work on your system?  Or you have the latest version, and those work?


>> You are right, this things would look better as Qt widgets, and my
>> understanding is that these functions are going to be rewritten that
>> way. There's no reason for them to be limited to use java.
>
> True.
> But perhaps the Java-based dialog functions can still be present, yet
> shadowed by other (Qt? OpenGL?) versions. At least they do work now so these
> ML-compatible functions are now implemented.

Sure.  I meant that "errordlg" and "inputdlg" seem like they shouldn't
be in a java subdirectory, but a more generic user interface directory.
  Perhaps "javaerrordlg" and "javainputdlg" is what should be in the
java directory.  If running without Qt IDE then inputdlg() would defer
to javainputdlg(), etc.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

John W. Eaton
Administrator
On 28-Nov-2012, Daniel J Sebald wrote:

| I meant that "errordlg" and "inputdlg" seem like they shouldn't
| be in a java subdirectory, but a more generic user interface directory.
|   Perhaps "javaerrordlg" and "javainputdlg" is what should be in the
| java directory.  If running without Qt IDE then inputdlg() would defer
| to javainputdlg(), etc.

Sure.  I copied the entire java package into Octave because it seemed
like the simpler thing to do.  I admit that I didn't do a lot of
testing beyond getting things to compile on my system.  At least that
much worked for me when I checked it in.  Sorry about the breakage,
but we'll eventually fix all these issues.  I don't have time at the
moment to do the work myself.  Maybe in a week or two.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

PhilipNienhuis
In reply to this post by Daniel Sebald
Daniel J Sebald wrote:

> On 11/28/2012 01:41 PM, Philip Nienhuis wrote:
>> Carnë Draug-2 wrote
>>> On 28 November 2012 02:58, Daniel J Sebald&lt;
>>
>>> daniel.sebald@
>>
>>> &gt; wrote:
>>>> Regarding some of the functions in the java package and directing to
>>>> the
>>>> broader list, are the names "errordlg", "helpdlg", etc. language
>>>> standards?
>>>> If not, I wonder if their names should include "java" in some way. The
>>>> reason I wonder is because if one launches Octave with the new GUI/IDE
>>>> then
>>>> it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
>>>> Java. That way, it is the same look and feel and uses just one software
>>>> exterior.
>>>>
>>>> I just tried creating some Java dialog boxes under the Octave IDE
>>>> and it
>>>> crashes on my system. Should we start entering bugs for Java in the
>>>> tracker, or wait a while?
>>
>> They work all right on my Linux box even when invoked from the GUI.
>>
>> But I see now that JWE has apparently transferred older versions of the
>> dialog m-files into core Octave.
>>
>> IIRC I have updated them last June and July for minor style changes
>> and to
>> accept multiline input for the MESSAGE argument (i.e., cellstr
>> arrays). It
>> also says so on the Java package page f. version 1.2.9, function
>> details, on
>> the OF website.
>
> I tried the inputdlg() in octave-cli and that works with multiple lines.
> (It gives an arcane error about java.xyz something if the input format
> is not a cellstr. That should be changed to a meaningful error statement
> conditioned in the script file.)
>
> You're saying the versions of the java interactive elements now in
> Octave work on your system? Or you have the latest version, and those work?

Yep, they just work. But not as smooth as in the latest java-1.2.9 pkg.

Perhaps you could download that, extract the *dlg.m files from the
./inst subdir and swap them into place into the scripts/java subdir,
just to try and see if they work more reliable.

>>> You are right, this things would look better as Qt widgets, and my
>>> understanding is that these functions are going to be rewritten that
>>> way. There's no reason for them to be limited to use java.
>>
>> True.
>> But perhaps the Java-based dialog functions can still be present, yet
>> shadowed by other (Qt? OpenGL?) versions. At least they do work now so
>> these
>> ML-compatible functions are now implemented.
>
> Sure. I meant that "errordlg" and "inputdlg" seem like they shouldn't be
> in a java subdirectory, but a more generic user interface directory.
> Perhaps "javaerrordlg" and "javainputdlg" is what should be in the java
> directory. If running without Qt IDE then inputdlg() would defer to
> javainputdlg(), etc.

I have similar ideas, but IMO renaming the Java based dialog functions
doesn't make much sense until there's a wrapper or so taking care of
running the proper version based on Qt, OpenGL or whatever graphics
toolkit is active.
BTW __java_inputdlg__.m etc. would make more sense.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

PhilipNienhuis
In reply to this post by John W. Eaton
John W. Eaton wrote:

> On 28-Nov-2012, Daniel J Sebald wrote:
>
> | I meant that "errordlg" and "inputdlg" seem like they shouldn't
> | be in a java subdirectory, but a more generic user interface directory.
> |   Perhaps "javaerrordlg" and "javainputdlg" is what should be in the
> | java directory.  If running without Qt IDE then inputdlg() would defer
> | to javainputdlg(), etc.
>
> Sure.  I copied the entire java package into Octave because it seemed
> like the simpler thing to do.  I admit that I didn't do a lot of
> testing beyond getting things to compile on my system.  At least that
> much worked for me when I checked it in.  Sorry about the breakage,
> but we'll eventually fix all these issues.

That's okay, I suppose it usually goes like that when new features get
implemented.

But I'm curious - what Java package version did you use? I'm sure it
must be an older version than the most recent 1.2.9

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

John W. Eaton
Administrator
On 29-Nov-2012, Philip Nienhuis wrote:

| John W. Eaton wrote:
| > On 28-Nov-2012, Daniel J Sebald wrote:
| >
| > | I meant that "errordlg" and "inputdlg" seem like they shouldn't
| > | be in a java subdirectory, but a more generic user interface directory.
| > |   Perhaps "javaerrordlg" and "javainputdlg" is what should be in the
| > | java directory.  If running without Qt IDE then inputdlg() would defer
| > | to javainputdlg(), etc.
| >
| > Sure.  I copied the entire java package into Octave because it seemed
| > like the simpler thing to do.  I admit that I didn't do a lot of
| > testing beyond getting things to compile on my system.  At least that
| > much worked for me when I checked it in.  Sorry about the breakage,
| > but we'll eventually fix all these issues.
|
| That's okay, I suppose it usually goes like that when new features get
| implemented.
|
| But I'm curious - what Java package version did you use? I'm sure it
| must be an older version than the most recent 1.2.9

I'm fairly certain that I updated the Octave Forge svn and used the
files I found in trunk/octave-forge/extra/java.  But if that's not the
case, let's fix the problem.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

PhilipNienhuis
John W. Eaton wrote:

> On 29-Nov-2012, Philip Nienhuis wrote:
>
> | John W. Eaton wrote:
> |>  On 28-Nov-2012, Daniel J Sebald wrote:
> |>
> |>  | I meant that "errordlg" and "inputdlg" seem like they shouldn't
> |>  | be in a java subdirectory, but a more generic user interface directory.
> |>  |   Perhaps "javaerrordlg" and "javainputdlg" is what should be in the
> |>  | java directory.  If running without Qt IDE then inputdlg() would defer
> |>  | to javainputdlg(), etc.
> |>
> |>  Sure.  I copied the entire java package into Octave because it seemed
> |>  like the simpler thing to do.  I admit that I didn't do a lot of
> |>  testing beyond getting things to compile on my system.  At least that
> |>  much worked for me when I checked it in.  Sorry about the breakage,
> |>  but we'll eventually fix all these issues.
> |
> | That's okay, I suppose it usually goes like that when new features get
> | implemented.
> |
> | But I'm curious - what Java package version did you use? I'm sure it
> | must be an older version than the most recent 1.2.9
>
> I'm fairly certain that I updated the Octave Forge svn and used the
> files I found in trunk/octave-forge/extra/java.  But if that's not the
> case, let's fix the problem.

Carnë deleted the Java package stuff from octave-forge. As for me I'd
rather had him "freeze" the Java package subdir instead of wiping it. OF
probably doesn't allow that.
With the new OF setup it became a lot harder for me to go back to before
Carnë's action, to find out what changes have to transferred to core
Octave compared to the version you imported. Probably not very much but
still a bit hard to find out now.

BTW the OF svn repo is a bit tricky as there's a revision number higher
up in the URL (at least for me when I access it tru http). If you used a
bookmark to go back to the Java package, chances are that the bookmark
referred to an earlier revision.

I only have my own (part of) OF repo on hard disk left, with svn icons
telling me that those latest patches I referred to have been committed
successfully.

Anyway, I'll see if I can fix this (= applying the latest Java patches)
the next days or week.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Carnë Draug-2
On 29 November 2012 23:01, Philip Nienhuis <[hidden email]> wrote:
> Carnė deleted the Java package stuff from octave-forge. As for me I'd rather
> had him "freeze" the Java package subdir instead of wiping it. OF probably
> doesn't allow that.

I wouldn't know how to do it.

> With the new OF setup it became a lot harder for me to go back to before
> Carnė's action, to find out what changes have to transferred to core Octave
> compared to the version you imported. Probably not very much but still a bit
> hard to find out now.

"svn log octave-forge/extra -l 3" shows the last 3 changes on the
extra directory, including that removing the java package was r11450.

To recover that, one can checkout the previous revision:

svn checkout http://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/java@11449

does the job.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

Philip Nienhuis
In reply to this post by Daniel Sebald
Daniel Sebald wrote
On 11/27/2012 02:58 PM, Ben Abbott wrote:
:
<snip>
:
> When I try "dlgtest(0)" I get ...
>
> Java JDK home directory  does not exist.
> Please adapt java_home in dlgtest.m.
>
> Setting JAVA_HOME to that used during the build gives ...
>
> setenv JAVA_HOME "/System/Library/Frameworks/JavaVM.framework/Home"
>
> Now "dlgtest(0)" results in ...
>
> 0 ... STOP
> 1 ... listdlg tests
> 2 ... errordlg tests
> 3 ... warndlg tests
> 4 ... helpdlg tests
> 5 ... inputdlg tests
> 6 ... TeX code tests
> Run which test?   [0]>
>
> Is this the expected result?
>
> Ben

Yes.  When you run one of those tests there should be some dialog boxes
appear on the screen if Java is working properly.

BTW, I've just altered dlgtest on my local copy so that it doesn't
return if the JAVA_HOME variable isn't defined.  Instead, it issues the
current warning and continues on.  When unsetting the JAVA_HOME variable
with

export -n JAVA_HOME

the Java demo seems to still work properly.  I think this conditional
can be removed.  It isn't clear to me where/why JAVA_HOME definition is
required.  I'm guessing it is interior to Octave java support somewhere
and dlgtest() is assuming something about its requirement, but I keep
thinking Octave should just fall back on "java" and "javac" as set up by
the shell if nothing else.
This had already been fixed in Octave-Forge svn in late June:

(http://sourceforge.net/p/octave/code/10706/tree//trunk/octave-forge/extra/java/inst/dlgtest.m?diff=505e333171b75b10eb655d97:10705)

Note: Sourceforge SVN currently has problems and is very slow.

AFAICS JWE has definitely imported a Java pkg version from before June, 2012, and I think I know what might have deceived him into assuming it was up-to-date.
I'll investigate the next days/week what changes/patches to the late Java package SVN have to be re-applied to core Octave; I still have my own up-to-date svn repo on my dev box at home. (I made the last two or three Java package releases.)

IOW, please don't commit patches/changesets to the Java files, except the autotools, until I've sorted it out.

See bug #37834

Thanks,

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Jordi Gutiérrez Hermoso-2
In reply to this post by Carnë Draug-2
On 29 November 2012 17:27, Carnë Draug <[hidden email]> wrote:

> To recover that, one can checkout the previous revision:
>
> svn checkout http://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/java@11449
>
> does the job.

Also mirrored here, for now:

    http://hg.octave.org/forge

HTH,
- Jordi G.H.
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

PhilipNienhuis
In reply to this post by Carnë Draug-2
Carnë Draug wrote:

> On 29 November 2012 23:01, Philip Nienhuis<[hidden email]>  wrote:
>> Carnė deleted the Java package stuff from octave-forge. As for me I'd rather
>> had him "freeze" the Java package subdir instead of wiping it. OF probably
>> doesn't allow that.
>
> I wouldn't know how to do it.
>
>> With the new OF setup it became a lot harder for me to go back to before
>> Carnė's action, to find out what changes have to transferred to core Octave
>> compared to the version you imported. Probably not very much but still a bit
>> hard to find out now.
>
> "svn log octave-forge/extra -l 3" shows the last 3 changes on the
> extra directory, including that removing the java package was r11450.
>
> To recover that, one can checkout the previous revision:
>
> svn checkout http://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/java@11449
>
> does the job.

That is not the issue - remember I'm the one who made the last 2 or 3
Java package releases.
The issue is that I'd like to find out the history of a number of
individual files. That info was stored in O-F svn, I can't find it in my
local svn repo (not in readable format, that is).
The new SourceForge setup made it quite a bit harder to track it all
down, and at the moment they also have problems with their SVN viewer.

I could obviously simply copy the new (= most recent) ones from my local
SVN Java package repo over the Java files in my local core Octave
Mercurial repo and let hg do the job.
But I'm afraid a few pitfalls may be looming there. I'd rather be sure
about exactly what has to be updated.

Admittedly some clues are in the NEWS file in the java-1.2.9.tar.gz
package but I'm quite confident that info isn't complete as far as code
level goes.

(Hmmm, perhaps Jordi might interpret all this as a case for hg....;-) )

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Carnë Draug-2
On 29 November 2012 23:56, Philip Nienhuis <[hidden email]> wrote:
> The issue is that I'd like to find out the history of a number of individual
> files. That info was stored in O-F svn, I can't find it in my local svn repo
> (not in readable format, that is).

Having removed or not the files from the repo should make no
difference at all, you can access previous revision numbers anyway. I
do not understand what is the issue. This is a revision control
system, as long as you did not left stuff uncommitted, the whole
history is there.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Carnë Draug-2
On 30 November 2012 00:54, Carnë Draug <[hidden email]> wrote:

> On 29 November 2012 23:56, Philip Nienhuis <[hidden email]> wrote:
>> The issue is that I'd like to find out the history of a number of individual
>> files. That info was stored in O-F svn, I can't find it in my local svn repo
>> (not in readable format, that is).
>
> Having removed or not the files from the repo should make no
> difference at all, you can access previous revision numbers anyway. I
> do not understand what is the issue. This is a revision control
> system, as long as you did not left stuff uncommitted, the whole
> history is there.

Apologies if advance if the following is patronizing, that is not my intention.

## checkout last revision before removing package
svn checkout http://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/java@11449
cd java/
## check all changes on the java package since june
svn log -vr BASE:{"2012-06-01"}
## the same but limited to the last 10 changes
svn log -vr BASE:{"2012-06-01"} -l 10
## to see the changes in revision 10736
svn diff -c 10736
## to see all changes until revision 10736
svn diff -r 10736

And depending on your configuration, the diff may appear colored.

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

PhilipNienhuis
Carnë Draug wrote:

> On 30 November 2012 00:54, Carnë Draug<[hidden email]>  wrote:
>> On 29 November 2012 23:56, Philip Nienhuis<[hidden email]>  wrote:
>>> The issue is that I'd like to find out the history of a number of individual
>>> files. That info was stored in O-F svn, I can't find it in my local svn repo
>>> (not in readable format, that is).
>>
>> Having removed or not the files from the repo should make no
>> difference at all, you can access previous revision numbers anyway. I
>> do not understand what is the issue. This is a revision control
>> system, as long as you did not left stuff uncommitted, the whole
>> history is there.
>
> Apologies if advance if the following is patronizing, that is not my intention.
>
> ## checkout last revision before removing package
> svn checkout http://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/java@11449
> cd java/
> ## check all changes on the java package since june
> svn log -vr BASE:{"2012-06-01"}
> ## the same but limited to the last 10 changes
> svn log -vr BASE:{"2012-06-01"} -l 10
> ## to see the changes in revision 10736
> svn diff -c 10736
> ## to see all changes until revision 10736
> svn diff -r 10736
>
> And depending on your configuration, the diff may appear colored.

Thanks; and no, I have a thick skin ;-)
For Octave-Forge I use TortoiseSVN (on Windows); now, entering that URL
you gave in the repo browser doesn't resolve. Yesterday the Sourceforge
SVN didn't work at all for me - they also wrote on the resulting web
page that there were problems with ViewVC or so.

Anyway I made some progress; by trying out a few carefully selected io
package functions (that depend on specific Java stuff) I think I have a
fairly good idea now what has to be done.

(BTW: TortoiseSVN works again for me, I got the history now.)

Philip
Reply | Threaded
Open this post in threaded view
|

Re: dlgtest() no longer needs Octave package

Carnë Draug-2
On 30 November 2012 15:53, Philip Nienhuis <[hidden email]> wrote:
> For Octave-Forge I use TortoiseSVN (on Windows); now, entering that URL you
> gave in the repo browser doesn't resolve.

That must had been a TortoiseSVN probem then, it works fine for me.
That's why I didn't understood what the problem was, the commands
don't change whether the directory has been removed from head or not.

> Yesterday the Sourceforge SVN
> didn't work at all for me - they also wrote on the resulting web page that
> there were problems with ViewVC or so.

They have dropped ViewVC completely with the "new SorceForge". When
they released SourceForge beta, they stopped giving support for
projects using the old SourceForge, replying to upgrade it instead.
That's why we are stuck with their new buggy limited interface. I'm
sorry about that.

Carnë
Reply | Threaded
Open this post in threaded view
|

Java [WAS: Re: dlgtest() no longer needs Octave package]

Philip Nienhuis
In reply to this post by John W. Eaton
John W. Eaton wrote
On 29-Nov-2012, Philip Nienhuis wrote:

| John W. Eaton wrote:
<snip>
| >
| > Sure.  I copied the entire java package into Octave because it seemed
| > like the simpler thing to do.  I admit that I didn't do a lot of
| > testing beyond getting things to compile on my system.  At least that
| > much worked for me when I checked it in.  Sorry about the breakage,
| > but we'll eventually fix all these issues.
|
| That's okay, I suppose it usually goes like that when new features get
| implemented.
|
| But I'm curious - what Java package version did you use? I'm sure it
| must be an older version than the most recent 1.2.9

I'm fairly certain that I updated the Octave Forge svn and used the
files I found in trunk/octave-forge/extra/java.  But if that's not the
case, let's fix the problem.
OK, fixed now.

Intruigingly it turned out that svn changes from July 2012 were actually transferred, but svn changes dating from June before were not. (Go figure)

Anyway the main point is that (AFAICS) all patches etc. since java-1.2.8 have now been integrated in core Octave.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: java package and MacOS

bpabbott
Administrator
In reply to this post by bpabbott

On Nov 27, 2012, at 10:31 PM, Ben Abbott wrote:

> On Nov 27, 2012, at 10:23 PM, Michael Goffioul wrote:
>
>> On Tue, Nov 27, 2012 at 10:18 PM, Ben Abbott <[hidden email]> wrote:
>>
>> On Nov 27, 2012, at 10:01 PM, Daniel J Sebald wrote:
>>
>>> On 11/27/2012 08:45 PM, Ben Abbott wrote:
>>>>
>>>> On Nov 27, 2012, at 6:14 PM, Daniel J Sebald wrote:
>>> [snip]
>>>>> Well, if you have Java on your system (which I assume is the case if you do any web browsing...type "java" or "javac" at a shell command line to confirm) then this should be a configuration issue (emphasis "should").  Java is supposed to be a very portable environment.
>>>>>
>>>>> Perhaps your definition of JAVA_HOME is wrong, but in my case I can set JAVA_HOME to any valid directory and "dlgtest(0)" functions properly.
>>>>>
>>>>> Dan
>>>>
>>>> MacOS X has Java.  If I understand the problem correctly ,.. the problem is that for MacOS X, the GUI loop must be in the main program thread.  What I'm not sure of is if the GUI loop  can support both a Qt and Java (I suspect it can not, but don't know).
>>>
>>> Oh, you are running Octave as its GUI?  I think several of us have been running with the --no-gui option.
>>>
>>> I just found out a little while ago that running these Java commands while inside the GUI doesn't work.  Nothing happens or it crashes.
>>>
>>> Dan
>>
>> No.  The gui does not work yet on MacOS X.
>>
>> The problem with Qt is not the same as the problem for Java.  For the Qt GUI, the main thread includes the GUI loop (at least that is my understanding).  The problem for the gui on MacOS X has to do with forking.  I get the error below.
>>
>> The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
>> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>>
>> The problem with Java is that the GUI loop is not the main thread, but MacOS requires that the first thread spawned  be the main()/GUI thread (I'm not an expert in how Cocoa works, and am only repeating what I've read here and else were).
>>
>> There you obviously have a problem, you can't have Qt and Java running their own GUI loop in the main thread (at least not in a trivial way).
>>
>> Michael.
>
> Maybe I was confused,  Does the Java gui loop run in the main thread?
>
> Ben

My tip is now ...

hg tip
changeset:   15777:b8bcb2c7f3e8
tag:         tip
user:        Rik <[hidden email]>
date:        Wed Dec 12 16:03:46 2012 -0800
summary:     configure.ac: Search for jvm.dll on MingW/Cygwin platforms for Java.

Running dlgtest(1) results in ...

dlgtest (1)

0 ... STOP
1 ... listdlg tests
2 ... errordlg tests
3 ... warndlg tests
4 ... helpdlg tests
5 ... inputdlg tests
6 ... TeX code tests
Run which test?   [0] > 1
2012-12-12 21:11:45.716 octave[78603:2603] Apple AWT Java VM was loaded on first thread -- can't start AWT.

- test listdlg with selectionmode single. No caption, no prompt.
error: [java] java.lang.InternalError: Can't start the AWT because Java was started on the first thread.  Make sure StartOnFirstThread is not specified in your application's Info.plist or on the command line
error: called from:
error:   /Users/bpabbott/Development/mercurial/default/sources/scripts/java/listdlg.m at line 131, column 8
error:   /Users/bpabbott/Development/mercurial/default/sources/scripts/java/dlgtest.m at line 61, column 6
error:   /Users/bpabbott/Development/mercurial/default/sources/scripts/java/dlgtest.m at line 30, column 9

Looks like the Java thread isn't main(), but the first thread spawned by main()?

Ben


12