[texworks] New version 302/303

[Jonathan Kew]

On 6 Jun 2009, at 16:44, T T wrote:

> On 06/06/2009, Alain Delmotte <esperanto at swing.be> wrote:
>> Ok the new build 306 is available on my site.
>
> Thanks.
>
>> But making a test: there is an error *both* with and without any
>> information for the path in the typesetting preference.
>> I mean in 303, when there was something for the path, it worked,  
>> without
>> not; now it's not working at all.
>
> Bummer. Unfortunately I have to confirm that. This makes rev.306
> unusable on Windows.

Indeed. :(

>>> setDefaultPaths doesn't care whether tex (or anything else) is
>>> actually present in the predefined paths; it just returns the list  
>>> of
>>> paths, it's the typeset() function that will look for tools.
>
> Right, setDefaultPaths doesn't look for tex but it removes nonexistent
> dirs from the list. If none of the predefined defaults exists, then
> the returned list will be empty.

True, though (a) an empty list should still be valid for the purpose  
of adding the dirs from PATH; and (b) when defaultbinpaths isn't  
provided, the built-in defaults should include the dir where texworks  
itself is located, so at least that one probably exists!

>>>> If the return value is @Invalid() as for
>>>> binaryPaths, then we have the same problem.
>>>
>>> setDefaultPaths shouldn't ever be returning an empty list, though  
>>> even
>>> if it does, an empty list ought to be harmless.
>
> Are you sure? From my tests it looks like the problem occurs *only* if
> binaryPaths is an empty list.

Yes, so it seems, but I am still mystified by it.

> Perhaps this @Invalid() in .ini file
> indicates an empty value, but I would expect something like @Empty()
> rather than @Invalid(). Could you check what gets written to
> texworks.ini on Linux when you clear the search list in preferences?
> If it is something different then maybe we are onto something.

It writes @Invalid().

>>>> Note that the original PATH is repeated twice in the one passed  
>>>> to the
>>>> spawned process, which should not happen, because of the condition
>>>> (see above):
>>>>
>>>>    if (!binPaths.contains(s))  binPaths.append(s);
>>>>
>>>> So something is not right here.
>>>
>>> Rev 303 did not include that condition, it unconditionally added the
>>> PATH in typeset(). This was revised in r.306. So this part, at  
>>> least,
>>> is not a mystery.
>
> Right, my mistake. But it seems that those changes made things  
> worse. But why?

I don't know; they were supposed to be better! I guess it's time for  
me to try a Windows build and see if I can track down what's going  
wrong; this stuff seems to work fine on the other platforms.

> Hmmm, I think I will have to finally bite the bullet and get some
> build system of the ground. I just don't have the time to chase up all
> those dependencies... Any chances of providing a build system bundling
> everything necessary to build TW? That would certainly encourage more
> people to play with it, especially on Windows.

If someone would like to do this, it'd be fine with me; I don't have  
the time or expertise to provide such a build system myself. The page  
at http://code.google.com/p/texworks/wiki/BuildingOnWindows gives some  
guidance that may help.

>
> Cheers,
>
> Tomek
>
> PS. For previous revisions defaultbinpaths works if coma is used as
> the path separator instead of semicolon. That's the consequence of
> using `toStringList' method to convert it.

That makes sense, though it wasn't intended to be that way!

Thanks,

JK