Turns out I suddenly can't use my default mail client which declares Content-Type: text/html;
Anyway, here goes yet another attempt to reply: This [1] is what Josh wrote on pain points. [1] http://apache-royale-development.20373.n8.nabble.com/NextGenAS-tutorials-on-Royale-website-tp6582p6686.html Apache Royale Development - NextGenAS tutorials on Royale website<http://apache-royale-development.20373.n8.nabble.com/NextGenAS-tutorials-on-Royale-website-tp6582p6686.html> NextGenAS tutorials on Royale website. Hi, I contacted today Josh Tynjala, looking for the NodeJS tutorial he did that I could not find. It seems he refactored his site and change domain and the... apache-royale-development.20373.n8.nabble.com ________________________________ From: Alex Harui <[email protected]> Sent: Wednesday, February 5, 2020 8:23 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: YFiles, EPL, Apache Sebastian wrote to the list. He was having trouble responding because Apache is blocking incoming emails from Nabble these days. Sebastian is encouraging us to take over maintenance of the d.ts converter as the .d.ts file might contain more useful information than the JS file. He also explained the format of the JS file. He doesn't seem interested in generating a parse-able JS file and drawing in the Google Closure Compiler users base at this time. I don't remember what the pain points of the d.ts converter were. I believe it would be easier to write a utility that flips the order of APIs in the JS file to see if the result would be a valid Google Closure Externs file. But he is right that being able to consume d.ts files would be much more general purpose. -Alex On 2/5/20, 12:06 AM, "Yishay Weiss" <[email protected]> wrote: You’re right about yfiles being the only one needing a var prefix. I sent a more detailed response, but my mails are getting bounced from the list for some reason. Will try to work privately with Sebastian on this. From: Alex Harui<mailto:[email protected]> Sent: Tuesday, February 4, 2020 7:33 PM To: [email protected]<mailto:[email protected]>; Alex Harui<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: YFiles, EPL, Apache Looking more carefully at the file, I think the warning you posted should be the only one like that. Aren't you getting other errors for some of the classes? I don't know if Sebastian is still following this discussion, but it looks like with a few changes, that file could be a valid Google Closure Externs file and would then open up use of YFiles for folks who use the Google Closure Compiler, which would hopefully be a significant market for them. Yishay, if you have time you can either manually manipulate that file and get it to parse cleanly or write a tool that does it. I think you first have to change: /** * @namespace */ yfiles={}; To: /** * @namespace * @const */ var yfiles={}; Then find places where class members are defined before the class constructor and change the order. So I saw that their Map class constructor is on line 51, after the first Map member definition on line 22. Move line 51 with its JSDoc before line 22's JSDoc and see if the warning goes away and the Map class is generated. If you write a tool, it could just for a.b.c.x being defined before a.b.c. HTH, -Alex On 2/4/20, 7:18 AM, "Yishay Weiss" <[email protected]> wrote: The interfaces seem to be generated ok, but not classes. I’m getting warnings such as [java] WARNING: [yfiles]:14: WARNING - accessing name yfiles in externs has no effect. Perhaps you forgot to add a var keyword? [java] yfiles={}; [java] ^^^^^^ From: Alex Harui<mailto:[email protected]> Sent: Tuesday, February 4, 2020 6:33 AM To: [email protected]<mailto:[email protected]>; Alex Harui<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: YFiles, EPL, Apache Yishay, Did you try to run this file through the Royale Externs Compiler? It looks a lot like Google Closure Externs format to me. You might get lucky and it will "just work" or there will be errors and we can discuss whether YFiles wants to have a file that can be directly used by the Google Closure Compiler or not. -Alex On 2/3/20, 7:02 PM, "Alex Harui" <[email protected]> wrote: Is this JSDoc file on the internet so I can take a look? The Royale Externs Compiler uses Google Closure's JavaScript parser because externs/typedefs are supposed to be a specially-formatted but valid JavaScript, so an AST (different from the one that we generate from MXML/AS) can be created from Closure-compatible JavaScript. It may be possible/better to work from the Closure AST in this case. HTH, -Alex On 2/3/20, 6:57 PM, "Yishay Weiss" <[email protected]> wrote: Yes, they do have a jsdoc file. Do you think it would be easier to maintain a conversion tool for that? ________________________________ From: Alex Harui <[email protected]> Sent: Monday, February 3, 2020 8:54:00 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: YFiles, EPL, Apache I think I'm missing something. Sebastian seemed to be saying there is a JSDoc-annotated Javascript file that YFiles maintains. Josh's tool was for d.ts files. If the JSDoc JS file is compatible with Google Closure's format, we might be able to consume that. -Alex On 2/3/20, 11:51 AM, "Yishay Weiss" <[email protected]> wrote: Josh had a tool [1] for converting d.ts to typedefs but he said it was a full-time job maintaining it and thus aborted. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBowlerHatLLC%2Fdts2as&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623434558&sdata=MZ9xPXp5DDU5z11JTO67hcYFUocOs8hES03Qmpx04XQ%3D&reserved=0 [https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F13039185%3Fs%3D400%26v%3D4&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623434558&sdata=MPyhTOdGFngnEC0UFXnNRMRhR5EjvekX2laq0lSBBME%3D&reserved=0]<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBowlerHatLLC%2Fdts2as&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623434558&sdata=MZ9xPXp5DDU5z11JTO67hcYFUocOs8hES03Qmpx04XQ%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F13039185%3Fs%3D400%26v%3D4&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=wHz1Pm%2B5GyRNCwCn3xwqDufUlkGp93bBFjF%2BVgvj16o%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F13039185%3Fs%3D400%26v%3D4&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=wHz1Pm%2B5GyRNCwCn3xwqDufUlkGp93bBFjF%2BVgvj16o%3D&reserved=0>>> GitHub - BowlerHatLLC/dts2as: Convert TypeScript definitions (d.ts files) into ActionScript classes and interfaces for use as external libraries with Apache FlexJS<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBowlerHatLLC%2Fdts2as&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=dJMOD2qP33vtLCCmBLSu88zfFTpfnzs3XpoaynHhiD8%3D&reserved=0> Convert TypeScript definitions (d.ts files) into ActionScript classes and interfaces for use as external libraries with Apache FlexJS - BowlerHatLLC/dts2as github.com ________________________________ From: Alex Harui <[email protected]> Sent: Monday, February 3, 2020 4:40 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: YFiles, EPL, Apache I'm wondering what the "API definition files" look like. Maybe we can quickly write a tool to generate the typedefs. -Alex On 2/3/20, 5:07 AM, "Yishay Weiss" <[email protected]> wrote: Sebastian, on the subject of derivative work on public repos, you might want to contact the author of this [1] externs file. He has a long list of externs files [2] that were derived from around 3 years ago from DefinitelyTyped [3]. We would, of course, not be using this [1] in light of your constraints on derivative work. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fhonzabrecka%2Fts-to-goog%2Fmaster%2Fexterns%2Fyfiles.extern.js&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=opYbu%2FZi5FNTCglbo3MIpBTl62%2F%2FW%2FgmStv2XD%2FMn4w%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhonzabrecka%2Fts-to-goog%2Ftree%2Fmaster%2Fexterns&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=E0d6LZikH4bkEZhyzuUrQEctIgjReFC%2FV3T3YkdH4Q4%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhonzabrecka%2Fts-to-goog&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=4Oo1A%2BBuayM%2BqRGZFOfIOXGNx2TJz5Sjw6v3SvksJg4%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhonzabrecka%2Fts-to-goog%2Ftree%2Fmaster%2Fexterns&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=E0d6LZikH4bkEZhyzuUrQEctIgjReFC%2FV3T3YkdH4Q4%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhonzabrecka%2Fts-to-goog%2Ftree%2Fmaster%2Fexterns&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=E0d6LZikH4bkEZhyzuUrQEctIgjReFC%2FV3T3YkdH4Q4%3D&reserved=0>>> [3] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDefinitelyTyped%2FDefinitelyTyped&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=iOtFoyOQmysldJKNTUeIw4AXNLXcHMTMvfvV%2FNOA9Eg%3D&reserved=0 From: Yishay Weiss<mailto:[email protected]> Sent: Monday, February 3, 2020 2:57 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: YFiles, EPL, Apache As promised, here is the summary of my correspondence with yFiles. > My questions to Sebastian from yWorks: > > a) Would yWorks allow us to create and publish typedefs (think of them > as Royale d.ts files) in our GitHub repository? I would also need to > check license issues on the Apache side. Our license does not allow publishing such files, which would be derivative works from files which are currently under our proprietary license. Although we could grant you permission to do that, we are currently very hesitant to do so. Here's why: Unless there is someone who actively maintains these typings, they would quickly become outdated because with every new release we add new features and APIs. The only way someone could reasonably maintain such a file (about 10k public API members, 7 MB TypeScript definition file) would be through a (semi-automatic?) conversion process. Thus both from a practical and legal perspective it would make a lot more sense to have a tool that reads our API definition files and creates the typedefs. Any licensed yFiles user could make use of this tool and would always get the typedefs matching her yFiles version. For you reference: This is what someone else did to get yFiles for HTML to work seemlessly with Kotlin/JS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fturansky%2Fyfiles-kotlin&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=qll5kKxd3lInepBL54sqotRwwzcSVThJc%2F48N9IwylA%3D&reserved=0 They got explicit permission from us for this (because they do not publish the original files). > > b) Would yWorks consider porting yFiles to Royale? Yes, if and once we get reasonable amount of feedback and customer interest. If you're interested in licensing yFiles for Apache Royale, please do state so and/or contact our support team: yworks.com/contact<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fyworks.com%2Fcontact&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623444514&sdata=n4p4VsZMPFrM1K6PMpq6BJvjpYxrILtilBRoBVSqrZY%3D&reserved=0> FWIW the vast majoriy of our previous yFiles FLEX customers has successfully migrated to "native web" technologies and is now happily using yFiles for HTML: With the current state of Apache Royale and the web, we don't see that Apache Royale has gained enough traction that would justify the efforts. We currently believe that creating the diagramming part using "classic" TypeScript/JavaScript and wrapping the resulting component up in a small Royale component with a tiny API surface is the superios and more efficient approach. From: Yishay Weiss<mailto:[email protected]> Sent: Sunday, January 12, 2020 11:37 PM To: [email protected]<mailto:[email protected]> Subject: RE: YFiles, EPL, Apache Ok, I contacted them. I’ll let you guys know. ________________________________ From: Carlos Rovira <[email protected]> Sent: Sunday, January 12, 2020 6:58:17 PM To: [email protected] <[email protected]> Subject: Re: YFiles, EPL, Apache Hi, I think you should contact yFiles directly and talk with them about it. That's better to try to figure if something could be wrong in the future. My understanding is that he should be able to give you permission since it implies make his commercial lib to clients that want to use in Royale. So that clientes will still need to pay for the commercial version, while if no typedefs are done, it will be more difficult to do. El dom., 12 ene. 2020 a las 16:30, Yishay Weiss (<[email protected]>) escribió: > > Hi, > > Before I start making inquiries in legal I wonder if anyone here can give > me some guidance. > > I want to create typedefs for yFiles [1], using an externs [2] file that’s > under an EPL [3]. Should that be a problem? > > This issue [4] makes me extra cautious. > > Thanks. > > [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yworks.com%2Fproducts%2Fyfiles-for-html&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623454469&sdata=slXu8Ddrx%2FJ6wLBPmzzXTyl9fLlPfZFAK97rB7LGEfA%3D&reserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fhonzabrecka%2Fts-to-goog%2Fmaster%2Fexterns%2Fyfiles.extern.js&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623454469&sdata=g%2FINc05LaGKDnWYFa1hnWtfXh52VBnD76Zs8Vampf0U%3D&reserved=0 > [3] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhonzabrecka%2Fts-to-goog%2Fblob%2Fmaster%2FLICENSE&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623454469&sdata=vd9zuLouHhMI%2ByovqI4Uy%2FqNgtegO8%2FaQ%2FhZnI4SeMw%3D&reserved=0 > [4] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDefinitelyTyped%2FDefinitelyTyped%2Fissues%2F23310&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623454469&sdata=psvygNG2%2F%2F5IlP49G0sUOc2%2BNRaNR9mHaGDaLdbWWFY%3D&reserved=0 > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2e2303d87f3149272d4908d7aa123d22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637164867623454469&sdata=j5YsKuAXvyFTDjRcgsOp1ksLCfZQ42BhcSXvYvtdnZo%3D&reserved=0
