Wine effect

[ChrisMW]

Under EA10, much the same as under 12.1. The progress window does mention that it is processing classes, and it even mentions layouting the diagrams, but nothing is added to the project, only packages and diagrams.

As to check the recursion, I went for the packager per directory option, and that does display the folder tree correctly, so it seems it's the java classes, having the extension .java

Going back to 13, the black bar only appears for items that do not have sub items. During the import it actually lists the classes (I kept using the package per directory option), but non of them make it into the project. So it doesn't seem a problem with the recursion, more with either reading the file (but it knows the class name, rather than the filename, so it seems unlikely) or adding the result to the project.

I'll start exploring the wine upgrade option...

[ChrisMW]

Ok, it took a little time, but I moved Wine from 1.6.2 to 1.8.4, I found on the Debian Jessie backports. I found another link, but those debs stuffed my installation in a very profound way, so I had to fix that first. I then made the mistake of creating a 64 bit prefix, which caused a host of problems for ODBC. So now I have the 32bit prefix, 1.8.4 and EA13. Needed to update winetricks to get the fonts to install properly, but that's easy.

The good news is that the black bars are completely gone, so the screen looks better.  The import does work better, although there are still a few things that work differently from what I'd expect.

I also tried running EA under wine, as in wine ea.exe > ea.log and this yielded a log file of zero bytes. So I then tried wine ea.exe > ea.log 2>&1 and now I'm seeing lots of

err:ole:CoGetClassObject no class object {88d96a05-f192-11d4-a65f-0040963251e5} could be created for context 0x17
err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111
err:ole:create_server class {88d96a05-f192-11d4-a65f-0040963251e5} not registered

So I reran and these messages all appear whilst loading.

I then used the 'overwrite' options and all loaded perfectly. So I checked and yes, the old import was in the same repo.... 

However, that made me wonder, if I import and have the classes synced, shouldn't they have appeared on the diagram, but referencing the existing class location. Which would have helped, as I would have seen the diagrams having classes, but the classes not being in the same location, it's trivial to find where they are once you see something on the diagrams. However, the diagrams were empty.

So going back is probably not worthwhile, and probably has something to do with it (remember my first import was using Wine 1.6.2 and EA 13 and the sync option with no previous code elements present, which failed, which was the reason I tried under windows). But using Wine 1.8.4, EA 13 and the overwrite option works properly, and displays properly as well. You must however create a 32bit prefix, because a 64bit prefix creates a problem with ODBC. Under wine it doesn't matter if you start the 32 or 64 ODBC manager, because it seems the same, you see 32+64 sources in the same list, regardsless of which one you start. EA throws a 193 error, which others report is a stack problem when using the 64 bit ODBC manager. The windows work around does not work under wine.

Also, using this setup still has the system DSN problem, at least for PostgreSQL. They all must configured as user DSN's.

[Eve]

Hi Chris,

Sounds like you went through quite an ordeal to test other versions. I hope the end result it worth it.

I'm glad you picked up diverting the stderr from wine as well. I'm kind of new to debugging issues with wine, so I didn't think of that. Hopefully that's enough information and we don't need to add any WINEDEBUG flags to the execution to get something useful.

The code import has only ever added new classes to diagrams. I think the idea is that existing classes are already on the necessary diagrams. I didn't think of that because for any non-trivial directory import I'll always turn off diagram creation. They are rarely useful and make the import take much longer.

Your comments about ODBC being broken under 64 bit are interesting. I've tested that myself (although with a 1.9 series of Wine) successfully. It occurs to me if Wine is showing them both in the same list, it may mean that EA will end up loading a connection using a 64 bit driver. That couldn't possibly work. Do you remember if you installed a 64 bit odbc driver when using the 64 bit bottle?

I've done a bit of follow up this morning with the developers chasing the System DSN issue. So far they haven't been able to confirm it, but I suspect it's actually related to 32 bit versions of Windows (and Wine?)

[ChrisMW]

Hi Simon,

Well Wine 1.8.4 seems to work better, but Debian and Wine are not a trivial match. I had to sequence the backports carefully to get it installed, and resort to the command line, Synaptic wasn't coping well.

About the import, the thing is, it does create diagrams, loads, within the spot you do the 'import source dir' , but they are all empty. If the assumption is that the existing classes are already on the diagrams, then why create loads of new empty ones. Also, if I switch on overwrite, it will remove the existing classes leaving the original diagrams empty.

I personally think this is confusing, wouldn't it be more straightforward to simply check during import, and if there's an existing structure, ask if the user wants to import a copy here, or update the existing branch in the repository? Because the package structure can be altered, trying to update a previous import can be a little hard. It seems a little hard to predict the end result, and I do use the import source dir to close the feedback loop. I'm good with cloning, I'm good with rewriting the original import, but I'm struggling with creating loads of empty diagrams (because the previously imported ones were synced and remain on those diagrams) and not knowing where the classes did end up (multiple people working on the same repo), or re-creating the package/diagram/classes in my part of the repo, but then affecting other parts of the repo. I now know sort of what to expect, but not sure I'll remember.....

As for the ODBC, I installed both. In the list you see both, I was careful to select the 32bit version in EA.

As for the system DSN issue, as I had to create a wineprefix from scratch, and it happens there, that might be easiest route to reproduction. My W7/64 doesn't have any issues using the system DSN. The 32bit W7 I was testing is an old VM and I'm not sure the installation is clean enough (having installed/removed lots of software over time, it might be a 'dirty' windows. I'll give my only other 32bit machine a go, but that's W10. But it's a cleaner environment. Any plans to go 64bit with EA?

[ChrisMW]

Simon,

I tried EA13 and W10/32bit, straight from the install it doesn't work. It had a EA11.13 on it and some old ODBC links, a few that still work (as they point to the PostgreSQL on the Linux host). So I simply upgraded 13, rebooted (because when in doubt, with windows, reboot  ) and tried to connect. 11.13 connected fine, 13.05 throws the error. So for me it seems predictable, a 32bit windows requires an user DSN, a 64bit windows does work with a 32bit system DSN.

I'd love to try the latest Wine, but 1.8.4 is not happy with a 64/32 wineprefix, although EA 13 runs fine, the ODBC is messed up. Not sure I'm going to go with 1.9, I quite like the way EA works with wine now, and 1.8.4 is almost the latest stable version (1.8.5 currently), and available as a back-port for my system. Giving the time it would take, a roll your own 1.9.x on a Debian based 64/32 system is probably interesting, not sensible from a production POV. I might have a old Linux laptop lying around that I could try, not sure if it still works... I'll see what I can do, testing with Wine is easier, as setting up a new prefix is quite quick.

[Eve]

I can confirm that the System DSN failure is the result of a bug that relates specifically to 32 bit versions of Windows (and Wine is faithful enough to Windows that it happens there too)

Expect a 1307 build that fixes that in the next week. (My personal estimate, not a Sparx Systems guarantee)

It sounds like you don't have any other Wine specific issues. If so, that's great and I certainly wouldn't be trying to get the development branch working.

[ChrisMW]

Thanks Simon,

After trying Play On Linux, and more recent wine, I've decided to stick with the stable wine release from the jessie backports and q4wine + winetricks. It is faster, and it seems easier to tweak than the other option. EA is now running even better on Linux, thanks to your feedback/comments/suggestions and one more bug squashed. All good. Thanks again......