Re: 0.9.10 Release

[Josh Tynjala]

My latest commits make the Jewel and JewelJS SWC files match between my
macOS and Windows machines. I ended up having to switch to a different
Maven Sass plugin because I realized the one we were using was no longer
maintained, and it was misbehaving. This new plugin is based on the newer
Sass that doesn't support CRLF output at all, so the changes I talked about
in my previous email ended up being a strict requirement.

I still need to figure out the duplicate hoisted variables in MXRoyale.
I'll need to dive into that on another day.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Apr 6, 2023 at 9:57 AM Josh Tynjala 
wrote:

> Some more findings:
>
> The difference in Jewel appears to be caused by defaults.css. The Maven
> build at some point was updated to force Sass to output CRLF on Windows, to
> keep Git from saying that the file is modified after regenerating it.
> Unfortunately, this breaks the ability to do a cross-platform reproducible
> build because every other platform uses LF. I'm probably going to undo this
> change (sorry, Greg!).  However, it looks like adding a .gitattributes file
> to the repo allows us to force line endings for specific files or
> extensions, regardless of autocrlf behavior. It should provide the same
> benefit as Greg's commit, while restoring reproducible builds. Side note: I
> also found that modern Sass doesn't even provide the option to use CRLF, so
> this change is probably for the best because we may need to upgrade Sass in
> the future.
>
> The situation with duplicates of hoisted variables in
> MXRoyaleBase/MXRoyale in JDK 17 might be a threading conflict (and probably
> could happen with JDK 11 too, if conditions are correct). When the issue
> reproduces, I see that the function scope actually contains duplicate
> definitions of every local variable, instead of just one of each.
> Interestingly, if I add enough logging to help myself debug this issue, the
> scope ends up containing one of each local variable, and it doesn't
> duplicate the hoisted variables anymore. That makes me think multiple
> threads may be manipulating the scope.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Wed, Apr 5, 2023 at 2:42 PM Josh Tynjala 
> wrote:
>
>> Some preliminary findings:
>>
>> Jewel:
>> - Some plaintext [Embed] content was not matching up between macOS and
>> Windows. It was clearly a text encoding issue. I fixed a compiler bug
>> where it was using the system default encoding instead of UTF-8. A
>> workaround would be to use JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8.
>> - The SWF files inside the Jewel SWCs still do not match between my
>> machines. I still need to figure out why. Probably a missing compiler
>> option in the Jewel pom.xml file.
>>
>> MXRoyale and MXRoyaleBase:
>> - On Windows, I was seeing hoisted variables appear in the JS output
>> twice. I noticed that I was using JDK 11 on macOS, and JDK 17 on Windows.
>> When I switched to JDK 11 on Windows, the problem went away. It looks like
>> there's a bug in the compiler that needs to be fixed to support JDK 17.
>> Until then, I recommend building with JDK 11 or older (8 should be fine
>> too).
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Wed, Apr 5, 2023 at 10:11 AM Josh Tynjala 
>> wrote:
>>
>>> Alright, I built the distribution locally with Maven on two different
>>> machines, and I can see that the following SWCs don't match: Jewel,
>>> MXRoyale, and MXRoyaleBase
>>>
>>> It affects both the JS and SWF versions of the SWCs.
>>>
>>> I'll see what I can do.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC 
>>>
>>>
>>> On Mon, Apr 3, 2023 at 8:04 AM Josh Tynjala 
>>> wrote:
>>>
 Yes, it's on by default.

 I guess that there must be some other reason why the builds don't match
 up. I just happened to notice this, in particular, was different between
 the Ant build and the Maven build.

 You may need to extract the .swc files and manually compare the
 contents to see what is different.

 --
 Josh Tynjala
 Bowler Hat LLC 


 On Sun, Apr 2, 2023 at 4:01 AM Yishay Weiss 
 wrote:

> Is that option on by default? I just tried building both on release
> machine and locally and am still getting the mismatch.
>
>  failonerror="true" >
> 
> 
>  value="royale-release,apache-release,_reproducible-build,with-distribution,with-examples,with-manualtests,option-with-swf"
> />
> 
> 
> 
>
> Is how it gets built now locally. Intuitively debug info should not be
> part of the release but I need to look into it further.
> 
> From: Josh Tynjala 
> Sent: Tuesday, March 28, 2023 6:17 PM
> To: dev@royale.apache.org 
> Subject: Re: 0.9.10 Release
>
> Hey Yishay,

Re: [royale-compiler] branch develop updated: JSRoyaleEmitter: when reading plain text files for [Embed] metadata, read as UTF-8 instead of system default

[Josh Tynjala]

I ended up skipping the compiler option. Instead, [Embed] metadata with
mimeType="text/plain" can now optionally specify a charset attribute.

[Embed(source="file.txt",mimeType="text/plain",charset="CP1250")]
public var file:String;

To me, this makes more sense than a compiler option, since non-utf8
encoding should be rare. The vast majority of projects will be more likely
to have almost all embedded text files encoded as utf8, and only a small
number in a different encoding, for special circumstances.

--
Josh Tynjala
Bowler Hat LLC 


On Wed, Apr 5, 2023 at 4:06 PM Josh Tynjala 
wrote:

> Maybe a new compiler option that will let folks choose an encoding would
> be best. Default to a sane UTF-8, and let people opt into playing with
> weird encodings, if they need it.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Wed, Apr 5, 2023 at 3:58 PM Alex Harui 
> wrote:
>
>> There is a chance this will break someone on Windows where the file
>> system is not UTF8 and the data includes Windows-encoded characters that
>> reference a file or something like that.
>>
>> IIRC, that's why I decided to live with JAVA_TOOL_OPTIONS, so we don't
>> make a change that can't be overridden.
>>
>> -Alex
>>
>> On 4/5/23, 1:47 PM, "Greg Dove" > greg.d...@gmail.com>> wrote:
>>
>>
>> EXTERNAL: Use caution when clicking on links or opening attachments.
>>
>>
>>
>>
>> Nice find, Josh.
>>
>>
>> I was intending to look into some similar issue with resource*
>> .properties *files
>> as well.
>> We have definitely had the need to set utf8 file.encoding in
>> JAVA_TOOL_OPTIONS to get that to work the same as flex compiler did for
>> royale compiler (JS in particular, but I will try to check if royale swf
>> is
>> at odds also), in some work over the last 12-18 months.
>> This is just a mention, for your awareness, not a request for you to do
>> anything. I hope to find some time to spend on Royale work in the 2nd half
>> of April, so I will try to look into it then.
>>
>>
>> -- Forwarded message -
>> From: mailto:joshtynj...@apache.org>>
>> Date: Thu, Apr 6, 2023 at 8:31 AM
>> Subject: [royale-compiler] branch develop updated: JSRoyaleEmitter: when
>> reading plain text files for [Embed] metadata, read as UTF-8 instead of
>> system default
>> To: comm...@royale.apache.org  <
>> comm...@royale.apache.org >
>>
>>
>>
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>>
>> joshtynjala pushed a commit to branch develop
>> in repository https://gitbox.apache.org/repos/asf/royale-compiler.git <
>> https://gitbox.apache.org/repos/asf/royale-compiler.git>
>>
>>
>>
>>
>> The following commit(s) were added to refs/heads/develop by this push:
>> new 5669b4714 JSRoyaleEmitter: when reading plain text files for
>> [Embed] metadata, read as UTF-8 instead of system default
>> 5669b4714 is described below
>>
>>
>> commit 5669b4714118c1e2c2edf0e01360a39002e78033
>> Author: Josh Tynjala > joshtynj...@apache.org>>
>> AuthorDate: Wed Apr 5 13:31:34 2023 -0700
>>
>>
>> JSRoyaleEmitter: when reading plain text files for [Embed] metadata,
>> read as UTF-8 instead of system default
>>
>>
>> This matches the behavior of reading other text files, and avoids the
>> need for JAVA_TOOL_OPTIONS with file.encoding
>> ---
>> .../royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java |
>> 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>
>> diff --git
>>
>> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java
>>
>> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java
>> index 10bc04b4e..2f67e14f5 100644
>> ---
>>
>> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java
>> +++
>>
>> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java
>> @@ -1097,7 +1097,7 @@ public class JSRoyaleEmitter extends JSGoogEmitter
>> implements IJSRoyaleEmitter
>> File file = new File(FilenameNormalization.normalize(source));
>> try {
>> String newlineReplacement = "n";
>> - String s = FileUtils.readFileToString(file);
>> + String s = FileUtils.readFileToString(file,
>> "UTF-8");
>> s = s.replaceAll("\n", "__NEWLINE_PLACEHOLDER__");
>> s = s.replaceAll("\r", "__CR_PLACEHOLDER__");
>> s = s.replaceAll("\t", "__TAB_PLACEHOLDER__");
>>
>>
>>
>>

Re: [royale-compiler] branch develop updated: JSRoyaleEmitter: when reading plain text files for [Embed] metadata, read as UTF-8 instead of system default

[Josh Tynjala]

According to the compiler docs, .properties files are assumed to be UTF-8.

https://github.com/apache/royale-compiler/blob/apache-royale-0.9.9/compiler/src/main/java/org/apache/royale/compiler/internal/resourcebundles/PropertiesFileParser.java#L98-L100

--
Josh Tynjala
Bowler Hat LLC 


On Wed, Apr 5, 2023 at 7:21 PM Greg Dove  wrote:

> @Josh:
> That sounds good to me, and makes things easier compared to what I was
> considering.
>
>
> @Alex:
> I was going to compare the behavior of the most recent Flex compiler and
> the Royale compiler to understand/avoid issues, but obviously only with swf
> vs. swf.
> Then check for any difference in royale compiler swf vs. js.
>
> For Resource properties files I had only found one very. old 'known issue'
> mention from the Flex 2 compiler which said:
>
>- All strings in properties files must be Latin-1 or UTF-8 encoded.
>
> I don't have experience using anything other than utf-8 throughout the Flex
> years in these cases. The Flex 2 issue comment above seems to be quite
> restrictive for properties files. However that may have been 'fixed' in
> Flex 3 or Flex 4 compilers to allow more.
> I do suspect that even in more recent compilers it ought to have been utf-8
> by default though, I believe that is what we were seeing for the migration
> project I was involved with, where the utf-8 encoding setting was needed on
> the Royale compiler but not on the old Flex one.. My intention however was
> to try to verify that before making any changes. If we do what Josh is
> suggesting then I would skip that work and just go with the explicit (but
> default Utf8) config setting.
>
>
>
> On Thu, Apr 6, 2023 at 11:07 AM Josh Tynjala 
> wrote:
>
> > Maybe a new compiler option that will let folks choose an encoding would
> be
> > best. Default to a sane UTF-8, and let people opt into playing with weird
> > encodings, if they need it.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
> >
> >
> > On Wed, Apr 5, 2023 at 3:58 PM Alex Harui 
> > wrote:
> >
> > > There is a chance this will break someone on Windows where the file
> > system
> > > is not UTF8 and the data includes Windows-encoded characters that
> > reference
> > > a file or something like that.
> > >
> > > IIRC, that's why I decided to live with JAVA_TOOL_OPTIONS, so we don't
> > > make a change that can't be overridden.
> > >
> > > -Alex
> > >
> > > On 4/5/23, 1:47 PM, "Greg Dove"  > > greg.d...@gmail.com>> wrote:
> > >
> > >
> > > EXTERNAL: Use caution when clicking on links or opening attachments.
> > >
> > >
> > >
> > >
> > > Nice find, Josh.
> > >
> > >
> > > I was intending to look into some similar issue with resource*
> > > .properties *files
> > > as well.
> > > We have definitely had the need to set utf8 file.encoding in
> > > JAVA_TOOL_OPTIONS to get that to work the same as flex compiler did for
> > > royale compiler (JS in particular, but I will try to check if royale
> swf
> > is
> > > at odds also), in some work over the last 12-18 months.
> > > This is just a mention, for your awareness, not a request for you to do
> > > anything. I hope to find some time to spend on Royale work in the 2nd
> > half
> > > of April, so I will try to look into it then.
> > >
> > >
> > > -- Forwarded message -
> > > From: mailto:joshtynj...@apache.org>>
> > > Date: Thu, Apr 6, 2023 at 8:31 AM
> > > Subject: [royale-compiler] branch develop updated: JSRoyaleEmitter:
> when
> > > reading plain text files for [Embed] metadata, read as UTF-8 instead of
> > > system default
> > > To: comm...@royale.apache.org  <
> > > comm...@royale.apache.org >
> > >
> > >
> > >
> > >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > >
> > > joshtynjala pushed a commit to branch develop
> > > in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
> <
> > > https://gitbox.apache.org/repos/asf/royale-compiler.git>
> > >
> > >
> > >
> > >
> > > The following commit(s) were added to refs/heads/develop by this push:
> > > new 5669b4714 JSRoyaleEmitter: when reading plain text files for
> > > [Embed] metadata, read as UTF-8 instead of system default
> > > 5669b4714 is described below
> > >
> > >
> > > commit 5669b4714118c1e2c2edf0e01360a39002e78033
> > > Author: Josh Tynjala  > > joshtynj...@apache.org>>
> > > AuthorDate: Wed Apr 5 13:31:34 2023 -0700
> > >
> > >
> > > JSRoyaleEmitter: when reading plain text files for [Embed] metadata,
> > > read as UTF-8 instead of system default
> > >
> > >
> > > This matches the behavior of reading other text files, and avoids the
> > > need for JAVA_TOOL_OPTIONS with file.encoding
> > > ---
> > > .../royale/compiler/internal/codegen/js/royale/JSRoyaleEmitter.java |
> > > 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > >
> > > diff --git
> > >
> > >
> >
> 

Re: 0.9.10 Release

[Alex Harui]

Yuck.  Feel free to provide an example.

Isn't the CSS parsed by the compiler?  Maybe it can be "normalized" there?

-Alex

On 4/6/23, 10:23 AM, "Josh Tynjala" mailto:joshtynj...@bowlerhat.dev>> wrote:


EXTERNAL: Use caution when clicking on links or opening attachments.




> The Maven build at some point was updated to force Sass to output CRLF on
Windows
> Unfortunately, this breaks the ability to do a cross-platform
reproducible build because every other platform uses LF


I should add an important detail to this. Technically, the SWC writer
converts CRLF to LF for CSS files. You would think that would be enough.
But, it turns out that Sass generates CSS files with slightly different
formatting depending on if it is using LF or CRLF line endings. So even
when line endings are normalized in a post-processing step, the files still
won't match. Fun, right?


--
Josh Tynjala
Bowler Hat LLC  




On Thu, Apr 6, 2023 at 9:57 AM Josh Tynjala mailto:joshtynj...@bowlerhat.dev>>
wrote:


> Some more findings:
>
> The difference in Jewel appears to be caused by defaults.css. The Maven
> build at some point was updated to force Sass to output CRLF on Windows, to
> keep Git from saying that the file is modified after regenerating it.
> Unfortunately, this breaks the ability to do a cross-platform reproducible
> build because every other platform uses LF. I'm probably going to undo this
> change (sorry, Greg!). However, it looks like adding a .gitattributes file
> to the repo allows us to force line endings for specific files or
> extensions, regardless of autocrlf behavior. It should provide the same
> benefit as Greg's commit, while restoring reproducible builds. Side note: I
> also found that modern Sass doesn't even provide the option to use CRLF, so
> this change is probably for the best because we may need to upgrade Sass in
> the future.
>
> The situation with duplicates of hoisted variables in
> MXRoyaleBase/MXRoyale in JDK 17 might be a threading conflict (and probably
> could happen with JDK 11 too, if conditions are correct). When the issue
> reproduces, I see that the function scope actually contains duplicate
> definitions of every local variable, instead of just one of each.
> Interestingly, if I add enough logging to help myself debug this issue, the
> scope ends up containing one of each local variable, and it doesn't
> duplicate the hoisted variables anymore. That makes me think multiple
> threads may be manipulating the scope.
>
> --
> Josh Tynjala
> Bowler Hat LLC  
>
>
> On Wed, Apr 5, 2023 at 2:42 PM Josh Tynjala  >
> wrote:
>
>> Some preliminary findings:
>>
>> Jewel:
>> - Some plaintext [Embed] content was not matching up between macOS and
>> Windows. It was clearly a text encoding issue. I fixed a compiler bug
>> where it was using the system default encoding instead of UTF-8. A
>> workaround would be to use JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8.
>> - The SWF files inside the Jewel SWCs still do not match between my
>> machines. I still need to figure out why. Probably a missing compiler
>> option in the Jewel pom.xml file.
>>
>> MXRoyale and MXRoyaleBase:
>> - On Windows, I was seeing hoisted variables appear in the JS output
>> twice. I noticed that I was using JDK 11 on macOS, and JDK 17 on Windows.
>> When I switched to JDK 11 on Windows, the problem went away. It looks like
>> there's a bug in the compiler that needs to be fixed to support JDK 17.
>> Until then, I recommend building with JDK 11 or older (8 should be fine
>> too).
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC  
>>
>>
>> On Wed, Apr 5, 2023 at 10:11 AM Josh Tynjala > >
>> wrote:
>>
>>> Alright, I built the distribution locally with Maven on two different
>>> machines, and I can see that the following SWCs don't match: Jewel,
>>> MXRoyale, and MXRoyaleBase
>>>
>>> It affects both the JS and SWF versions of the SWCs.
>>>
>>> I'll see what I can do.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC  
>>>
>>>
>>> On Mon, Apr 3, 2023 at 8:04 AM Josh Tynjala >> >
>>> wrote:
>>>
 Yes, it's on by default.

 I guess that there must be some other reason why the builds don't match
 up. I just happened to notice this, in particular, was different between
 the Ant build and the Maven build.

 You may need to extract the .swc files and manually compare the
 contents to see what is different.

 --
 Josh Tynjala
 Bowler Hat LLC  


 On Sun, Apr 2, 2023 at 4:01 AM Yishay Weiss >>> >
 wrote:

> Is that option on by default? I just tried building both on release
> machine and locally and am still 

Re: 0.9.10 Release

[Josh Tynjala]

> The Maven build at some point was updated to force Sass to output CRLF on
Windows
> Unfortunately, this breaks the ability to do a cross-platform
reproducible build because every other platform uses LF

I should add an important detail to this. Technically, the SWC writer
converts CRLF to LF for CSS files. You would think that would be enough.
But, it turns out that Sass generates CSS files with slightly different
formatting depending on if it is using LF or CRLF line endings. So even
when line endings are normalized in a post-processing step, the files still
won't match. Fun, right?

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Apr 6, 2023 at 9:57 AM Josh Tynjala 
wrote:

> Some more findings:
>
> The difference in Jewel appears to be caused by defaults.css. The Maven
> build at some point was updated to force Sass to output CRLF on Windows, to
> keep Git from saying that the file is modified after regenerating it.
> Unfortunately, this breaks the ability to do a cross-platform reproducible
> build because every other platform uses LF. I'm probably going to undo this
> change (sorry, Greg!).  However, it looks like adding a .gitattributes file
> to the repo allows us to force line endings for specific files or
> extensions, regardless of autocrlf behavior. It should provide the same
> benefit as Greg's commit, while restoring reproducible builds. Side note: I
> also found that modern Sass doesn't even provide the option to use CRLF, so
> this change is probably for the best because we may need to upgrade Sass in
> the future.
>
> The situation with duplicates of hoisted variables in
> MXRoyaleBase/MXRoyale in JDK 17 might be a threading conflict (and probably
> could happen with JDK 11 too, if conditions are correct). When the issue
> reproduces, I see that the function scope actually contains duplicate
> definitions of every local variable, instead of just one of each.
> Interestingly, if I add enough logging to help myself debug this issue, the
> scope ends up containing one of each local variable, and it doesn't
> duplicate the hoisted variables anymore. That makes me think multiple
> threads may be manipulating the scope.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Wed, Apr 5, 2023 at 2:42 PM Josh Tynjala 
> wrote:
>
>> Some preliminary findings:
>>
>> Jewel:
>> - Some plaintext [Embed] content was not matching up between macOS and
>> Windows. It was clearly a text encoding issue. I fixed a compiler bug
>> where it was using the system default encoding instead of UTF-8. A
>> workaround would be to use JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8.
>> - The SWF files inside the Jewel SWCs still do not match between my
>> machines. I still need to figure out why. Probably a missing compiler
>> option in the Jewel pom.xml file.
>>
>> MXRoyale and MXRoyaleBase:
>> - On Windows, I was seeing hoisted variables appear in the JS output
>> twice. I noticed that I was using JDK 11 on macOS, and JDK 17 on Windows.
>> When I switched to JDK 11 on Windows, the problem went away. It looks like
>> there's a bug in the compiler that needs to be fixed to support JDK 17.
>> Until then, I recommend building with JDK 11 or older (8 should be fine
>> too).
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Wed, Apr 5, 2023 at 10:11 AM Josh Tynjala 
>> wrote:
>>
>>> Alright, I built the distribution locally with Maven on two different
>>> machines, and I can see that the following SWCs don't match: Jewel,
>>> MXRoyale, and MXRoyaleBase
>>>
>>> It affects both the JS and SWF versions of the SWCs.
>>>
>>> I'll see what I can do.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC 
>>>
>>>
>>> On Mon, Apr 3, 2023 at 8:04 AM Josh Tynjala 
>>> wrote:
>>>
 Yes, it's on by default.

 I guess that there must be some other reason why the builds don't match
 up. I just happened to notice this, in particular, was different between
 the Ant build and the Maven build.

 You may need to extract the .swc files and manually compare the
 contents to see what is different.

 --
 Josh Tynjala
 Bowler Hat LLC 


 On Sun, Apr 2, 2023 at 4:01 AM Yishay Weiss 
 wrote:

> Is that option on by default? I just tried building both on release
> machine and locally and am still getting the mismatch.
>
>  failonerror="true" >
> 
> 
>  value="royale-release,apache-release,_reproducible-build,with-distribution,with-examples,with-manualtests,option-with-swf"
> />
> 
> 
> 
>
> Is how it gets built now locally. Intuitively debug info should not be
> part of the release but I need to look into it further.
> 
> From: Josh Tynjala 
> Sent: Tuesday, March 28, 2023 6:17 PM
> To: dev@royale.apache.org 
> 

Re: 0.9.10 Release

[Josh Tynjala]

Some more findings:

The difference in Jewel appears to be caused by defaults.css. The Maven
build at some point was updated to force Sass to output CRLF on Windows, to
keep Git from saying that the file is modified after regenerating it.
Unfortunately, this breaks the ability to do a cross-platform reproducible
build because every other platform uses LF. I'm probably going to undo this
change (sorry, Greg!).  However, it looks like adding a .gitattributes file
to the repo allows us to force line endings for specific files or
extensions, regardless of autocrlf behavior. It should provide the same
benefit as Greg's commit, while restoring reproducible builds. Side note: I
also found that modern Sass doesn't even provide the option to use CRLF, so
this change is probably for the best because we may need to upgrade Sass in
the future.

The situation with duplicates of hoisted variables in MXRoyaleBase/MXRoyale
in JDK 17 might be a threading conflict (and probably could happen with JDK
11 too, if conditions are correct). When the issue reproduces, I see that
the function scope actually contains duplicate definitions of every local
variable, instead of just one of each. Interestingly, if I add enough
logging to help myself debug this issue, the scope ends up containing one
of each local variable, and it doesn't duplicate the hoisted variables
anymore. That makes me think multiple threads may be manipulating the scope.

--
Josh Tynjala
Bowler Hat LLC 


On Wed, Apr 5, 2023 at 2:42 PM Josh Tynjala 
wrote:

> Some preliminary findings:
>
> Jewel:
> - Some plaintext [Embed] content was not matching up between macOS and
> Windows. It was clearly a text encoding issue. I fixed a compiler bug
> where it was using the system default encoding instead of UTF-8. A
> workaround would be to use JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8.
> - The SWF files inside the Jewel SWCs still do not match between my
> machines. I still need to figure out why. Probably a missing compiler
> option in the Jewel pom.xml file.
>
> MXRoyale and MXRoyaleBase:
> - On Windows, I was seeing hoisted variables appear in the JS output
> twice. I noticed that I was using JDK 11 on macOS, and JDK 17 on Windows.
> When I switched to JDK 11 on Windows, the problem went away. It looks like
> there's a bug in the compiler that needs to be fixed to support JDK 17.
> Until then, I recommend building with JDK 11 or older (8 should be fine
> too).
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Wed, Apr 5, 2023 at 10:11 AM Josh Tynjala 
> wrote:
>
>> Alright, I built the distribution locally with Maven on two different
>> machines, and I can see that the following SWCs don't match: Jewel,
>> MXRoyale, and MXRoyaleBase
>>
>> It affects both the JS and SWF versions of the SWCs.
>>
>> I'll see what I can do.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Mon, Apr 3, 2023 at 8:04 AM Josh Tynjala 
>> wrote:
>>
>>> Yes, it's on by default.
>>>
>>> I guess that there must be some other reason why the builds don't match
>>> up. I just happened to notice this, in particular, was different between
>>> the Ant build and the Maven build.
>>>
>>> You may need to extract the .swc files and manually compare the contents
>>> to see what is different.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC 
>>>
>>>
>>> On Sun, Apr 2, 2023 at 4:01 AM Yishay Weiss 
>>> wrote:
>>>
 Is that option on by default? I just tried building both on release
 machine and locally and am still getting the mismatch.

 >>> failonerror="true" >
 
 
 >>> value="royale-release,apache-release,_reproducible-build,with-distribution,with-examples,with-manualtests,option-with-swf"
 />
 
 
 

 Is how it gets built now locally. Intuitively debug info should not be
 part of the release but I need to look into it further.
 
 From: Josh Tynjala 
 Sent: Tuesday, March 28, 2023 6:17 PM
 To: dev@royale.apache.org 
 Subject: Re: 0.9.10 Release

 Hey Yishay,

 I recently made a commit that adds the swf-debugfile-alias compiler
 option
 for SWC files built by Maven. This compiler option was being used by Ant
 already, but it never got added to the Maven build. And I think that
 binaries would fail comparison without it. This may be why Release Step
 11
 was failing for you.

 Basically, swf-debugfile-alias ensures that the debugging information in
 the SWC doesn't include the local path to the .as/.mxml source files
 (starting with something like C:\Users\joshtynjala\ or
 /Users/CoolGuy19/).
 Instead, it sets a generic path that will always match among builds from
 different machines. Considering this was missing, it sure sounds like a
 reason why binary comparison would fail.