Hi Alex,
I don't doubt you have reason, and take for sure that I want to be one more
person capable of contribute to compiler. Just think that I can't do so
many tasks in just few time: I need to code an entire application, I have
to add missed things to Jewel that are still not done, correct and
IMO, the project is at a greater risk if, when a bug is reported, there aren't
several people volunteering to fix it because they don't have experience fixing
certain kinds of issues.
Why would you choose any framework if you couldn't get timely support? This is
a great opportunity for someone
Hi Kenny,
Josh is working this days in fixing debugging with source maps.
Carlos
El vie., 19 oct. 2018 a las 16:18, Kenny Lerma ()
escribió:
> I'll need to get more familiar with the compiler code, but I'll certainly
> consider it. I don't know if Josh Tynjala is already working on the source
I'll need to get more familiar with the compiler code, but I'll certainly
consider it. I don't know if Josh Tynjala is already working on the source
maps again, but it's been hit or miss that the source maps chrome. So,
that needs to be looked into as well.
Kenny
On Fri, Oct 19, 2018 at 9:15 AM
Hi Kenny,
thanks for joining the discussion, I just reverse the commits that remove
source maps on release
Want do you think about work on that change and submit a PR? I could revise
it
Thanks
Carlos
El vie., 19 oct. 2018 a las 16:12, Kenny Lerma ()
escribió:
> Just my 2 cents, but I agree tha
Just my 2 cents, but I agree that the -source-map compiler flag should
decide if they are generated or not in release builds.
Kenny
On Thu, Oct 18, 2018 at 1:55 PM Josh Tynjala wrote:
> I mentioned to Carlos that he did not need to deploy the source maps in
> js-release to production. I did no
Hi Josh,
I think is a good idea. for now I'll put source maps for release mode as it
was, and from there, at some time introduce that improvement.
Thanks
El jue., 18 oct. 2018 a las 20:55, Josh Tynjala ()
escribió:
> I mentioned to Carlos that he did not need to deploy the source maps in
> js-re
Hi Alex
El jue., 18 oct. 2018 a las 18:51, Alex Harui ()
escribió:
> I did not realize source maps are gone. Please put them back in. There
> were useful at times. I don't understand why they were removed. Can you
> summarize the discussion?
>
Ok, my perception was that source maps on release
I did not realize source maps are gone. Please put them back in. There were
useful at times. I don't understand why they were removed. Can you summarize
the discussion?
If I needed some design work and nobody volunteered to do it, I'm pretty sure I
could pay someone to do it who had no knowl
HI Alex,
El jue., 18 oct. 2018 a las 0:26, Alex Harui ()
escribió:
> Hi Carlos,
>
> Well, that is my suggestion for how you can figure this out. In theory,
> there should be relatively few differences in js-debug and those few
> differences are likely to be the difference in the js-release versi
Hi Carlos,
Well, that is my suggestion for how you can figure this out. In theory, there
should be relatively few differences in js-debug and those few differences are
likely to be the difference in the js-release version.
Also, in theory, the source-maps work and running the js-release in the
Hi Alex,
one thing to take into account, you talk about to compare debug versions,
but the problem is that debug versions works right, so I think you'll
didn't find nothing related to the real problem there.
Thanks
El mié., 17 oct. 2018 a las 17:48, Carlos Rovira ()
escribió:
> Hi Alex,
>
> do y
Hi Alex,
do you want to send you a zip file with the js-debug versions?
In order to compare both je-relase versions, my problem is that I don't
know what I must look for, so is difficult to see things. In the other
hand, I'm spending lots of time in this kind of Debugging what makes me
unable to w
This may be a good opportunity for folks like you to develop skills at
debugging things like this. It won't scale if it is always up to me. IMO, I
would be comparing the un-minified source to see what is different. The
release files are hard to read.
-Alex
On 10/17/18, 6:58 AM, "Carlos Ro
Alex,
testing with the test change to the same jewel code and with actual repo
states fails in release mode as expected. So clearly something has changed
this days that makes MX RO fail in release mode.
Using DiffMerge to compare both release .js files shows a clear red zone
where the significant
Hi Alex,
Going to repos state of Oct, 14th (last commit of that day, in compiler and
framework, and in my project app repo as well), I can confirm all worked on
release more and communication with server is ok
for our mxroyale MX RO test: I can't get it to work in release mode either
adding:
deb
Hi Alex,
the compiler params I reported was not right, were from asconfig.json, but
since I'm using maven I saw there was not setup anything, so I setup to :
-source-map=true;-js-dynamic-access-unknown-members=true
And seems the output is still the same
[Error] TypeError: undefined is not an o
Ok. Let us know what you find out. I'm curious why you are not using
-js-dynamic-access. I thought that was at least a workaround.
-Alex
On 10/16/18, 2:36 PM, "Carlos Rovira" wrote:
Hi Alex,
I'm starting with our simple MXRoyale RO text example and our Java sample.
I just p
Hi Alex,
I'm starting with our simple MXRoyale RO text example and our Java sample.
I just pushed a commit to easy change between the old example and the new
MX RO test case, and enable RELEASE mode. When doing so and running it
doesn't work. this is the output
[Error] TypeError: undefined is not
Hi Carlos,
Are you saying you can see that the response from the server was received by
XHR in the browser?
I can't think of anything that I pushed yesterday that would affect response
handling. IMO, the changes I made affected the call to send(), but not the
response handling. The other cha
Hi Alex
It seems that latest changes makes MX RO not work in js-release mode.
If you remember I could by-pass this problem setting up
-js-dynamic-access-unknown-members=true
compiling my Application, but now testing js-release it's not working at
all, since we are in release no traces are shown
ca
Hi Alex,
with your latest fixes all is working ok :)
thanks!
El lun., 15 oct. 2018 a las 20:12, Alex Harui ()
escribió:
> Either syntax should work. I just pushed changes to AbstractService that
> got service.echo() to work.
>
> -Alex
>
> On 10/15/18, 10:51 AM, "Carlos Rovira" wrote:
>
> H
Either syntax should work. I just pushed changes to AbstractService that got
service.echo() to work.
-Alex
On 10/15/18, 10:51 AM, "Carlos Rovira" wrote:
Hi Alex,
one thing I not understand is that this:
(service.echo as Operation).send();
should be
ser
Hi Alex,
one thing I not understand is that this:
(service.echo as Operation).send();
should be
service.echo()
I think we're trying to remove "send()" and call directly "echo()"
I can go to your latest commits in both compiler and framework and try, but
don't understand the purpose, since cal
About 10 hours ago, after I cast the call to send in the example to be
(service.echo as Operation).send() , it worked for me.
I see you have made several changes to the example since. Go back to where the
example was about 10 hours ago, make that one change to service.echo.send() and
it should
Hi Alex,
El lun., 15 oct. 2018 a las 18:54, Alex Harui ()
escribió:
> There may be a couple of things affecting you. One is that in the bug you
> reported, it looks like only the first RO is created and the others are not.
>
I 'm pretty sure the bug about mx:method is not present since I test i
There may be a couple of things affecting you. One is that in the bug you
reported, it looks like only the first RO is created and the others are not.
Second, if you notice in the example, you'll see things like (service.echo as
Operation).lastResult. After adding support for callProperty, the
Hi Alex,
I added to the RO test example the CompressedRO test case commented to help
you find the problem.
I couldn't test like in net RO since now the entire example is failing, but
once the callProperty works for a normal case should help us to check if
the rest of RO works since it uses "conver
Hi Alex,
I found that even if I remove completely CompressedRemoteObject and use
only normal mx:RemoteObject the error shows:
[Error] TypeError: undefined is not an object (evaluating
'this.remoteObject.convertParametersHandler')
El lun., 15 oct. 2018 a las 13:00, Carlos Rovira ()
escribió:
Hi Alex,
I'm finding a problem with callProperty. I'm using a
CompressedRemoteObjeect that uses two hooks in RemoteObject API
public var convertParametersHandler:Function;
and
public var convertResultHandler:Function;
this makes the call fail with
[Error] TypeError: undefined is not an object
I pushed changes to the compiler and framework to try to get callProperty to
work. I don't have a test case but give it a try and see what happens.
If you compare the size of the output with and without -js-dynamic-access, you
can see the theoretical savings of not using that option. If that s
Hi Alex
El dom., 14 oct. 2018 a las 23:48, Alex Harui ()
escribió:
> I got the resources working so I will look into Proxy.callProperty.
>
>
That's cool, I'm closing for today, I can try in some hours if you upload
some changes. Thanks
> The issue with js-dynamic-access isn't about MX RemoteObj
I got the resources working so I will look into Proxy.callProperty.
The issue with js-dynamic-access isn't about MX RemoteObject vs Basic
RemoteObject, it is whether, if we fixed places in any of the code where
minification breaks things, what the size/performance trade-off would be. Some
vari
Hi Alex,
El dom., 14 oct. 2018 a las 18:32, Alex Harui ()
escribió:
> Hi Carlos,
>
> JS proxy doesn't support callProperty yet. Feel free to add it, or I will
> after I finish up ResourceManager.
>
JS proxy is mx.utlis.ObjectProxy or you mean maybe AbstractService
callProperty?
I could take a l
Hi Alex,
filed here: https://github.com/apache/royale-compiler/issues/53
just say that for me, this bug is not critical since I don't use
mx:methods, but maybe others approaching mx:RemoteObject will need it, or
is very useful for new comers to RemoteObject-AMF technology.
thanks
El dom., 14 o
Hi Carlos,
JS proxy doesn't support callProperty yet. Feel free to add it, or I will
after I finish up ResourceManager.
I don't doubt that minification breaks lots of things that js-dynamic-access
fixes. Hard to say how much smaller your app would be if we fixed anough stuff
without that opt
File a bug with a test case.
-Alex
On 10/13/18, 2:27 AM, "Carlos Rovira" wrote:
Hi Alex,
I get Responder/AsyncToken working with the current code.
But there's a bug:
To make it work I need to comment this part in the example
If not I get this w
Hi Alex,
I get all my ROs converted to MX ROs in my real world royale app and
working with AsyncToken/Responder, like we use to do with Swiz (just left
the metadata features like Inject, EventHandler, etc...that will be pursued
later as I have the time), so I think this is really good news, since
Hi Alex,
I get Responder/AsyncToken working with the current code.
But there's a bug:
To make it work I need to comment this part in the example
If not I get this when calling the second RO:
[Error] TypeError: undefined is not an object (evaluating
'this.serviceResp.getProperty')
sendEcho (A
Hi Alex,
thanks, I try it an now it's working :)
El vie., 12 oct. 2018 a las 19:55, Alex Harui ()
escribió:
> Hi Carlos,
>
> The Maven build for the RO example was using a template and the compiler
> wasn't using the right variable. In MXRoyale projects the main class name
> is not the same as
Hi Carlos,
The Maven build for the RO example was using a template and the compiler wasn't
using the right variable. In MXRoyale projects the main class name is not the
same as the MXML file name because we generate a SystemManager subclass like
Flex does.
Also, the MXRoyale.swc wasn't includ
VSCode is using released version of the compiler, that's why I have started
whole process to provide for Josh new version.
pt., 12 paź 2018 o 18:06 Alex Harui napisał(a):
> Hi Carlos,
>
> It is not possible for me to have tested every feature of RemoteObject.
> I'm sure there are bugs. Debug in
Hi Carlos,
It is not possible for me to have tested every feature of RemoteObject. I'm
sure there are bugs. Debug into the code and fix some of them. I've hardly
ever used RemoteObject so you know better than me what it can do.
Regarding VSCode, those errors sound like it is not using the la
Hi Alex,
while example in mx doesn't work form me as I reported in latest email (due
to *viewBead.beforeLayout* error), I was able to make MX RO work on a
custom simple example I'm creating as a duplicate of the old net RO test.
This are my findings:
1.- I can't get event result working at mx:me
Hi Alex,
I see you fixed poms and now all is building correctly in maven in my .m2
with 0.9.5-SNAPSHOT. I remove all .m2 artificats to build from a clean
state. Thanks, since all is now more clear.
When I tried to run the MX RO example build with maven it fails with this:
TypeError: null is not
Hi Alex,
I'm fixing version numbers in maven projects and when all is set to
0.9.5-SNAPSHOT, the error I announced up in this thread comes again:
[*INFO*] *--- *royale-maven-plugin:0.9.5-SNAPSHOT:compile-as
*(default-compile-as)* @ MXRoyale* ---*
[*INFO*] Executing COMPC in tool group Royale wit
Ok Alex,
I'm trying to create a basic test with Jewel and MX RO. First problem I get
is that "symbol" tag inside mx:arguments is not recognized
This tag could not be resolved to an ActionScript class. It will be ignored.
Maybe it's only recognized in MX environment? if so could it be enhanced to
I don't think RemoteObject is a bead. See the example at
examples/mxroyale/RemoteObjectAMFTest.
I got the ServerConfig error as well but it didn't seem to affect the example's
bin/js-debug version.
You might want to actually build your test setup with Flex so you know it
"will" work. For exa
Hi Alex,
I tried to use MX RO but doesn't work. Here's what the info of this test:
Code:
to make a quick test I put this code to run at "initComplete" event:
private function prepareChannelSet(event:Event):void
{
var amfEndpoint:String = "http://localhost:8080/webapp/messagebroker/my-amf";;
v
Hi Alex,
strangely, now build is passing locally...can't figure why yesterday it was
failing...maybe part of the build was in the change of day at 00:00...just
speculating..
I'll try to put mx RO to work and see I see and report :)
El jue., 11 oct. 2018 a las 12:18, Carlos Rovira ()
escribió:
Hi Alex,
yes, I always compile first compiler, then typedefs and last asjs.
I'll try again. Maybe the maven-prepare-release could be doing making some
problem with the change of version 0.9.4 to 0.9.5?
El jue., 11 oct. 2018 a las 9:30, Alex Harui ()
escribió:
> I can't reproduce the failure. I
I can't reproduce the failure. It worked on builds.a.o as well. Did you run
mvn on the compiler first?
-Alex
On 10/10/18, 4:38 PM, "Carlos Rovira" wrote:
I must close for today, tomorrow will try to change net RO for mx RO if you
finally get this build error fixed.
Thanks
I must close for today, tomorrow will try to change net RO for mx RO if you
finally get this build error fixed.
Thanks
Carlos
El mié., 10 oct. 2018 a las 23:34, Carlos Rovira ()
escribió:
> That's great Alex! :)
>
> I want to try it but I found the following error building with maven:
>
>
> [*
That's great Alex! :)
I want to try it but I found the following error building with maven:
[*INFO*] *< *org.apache.royale.framework:MXRoyale*
>*
[*INFO*] *Building Apache Royale: Framework: Libs: MXRoyale 0.9.4-SNAPSHOT
[32/118]*
[*INFO*] *-
We especially want the RemoteObject in Network.swc to be PAYG. MX RemoteObject
was never PAYG.
Having looked at the code more, I see what you are saying about Operation not
having its own fault and result handlers. It looks like there already is a
SimpleOperation, so Operation could introduce
Hi Alex
El mar., 9 oct. 2018 a las 18:14, Alex Harui ()
escribió:
> As long as Responders are PAYG and not baked into the basic RO
> implementation, it is fine for others to try to replicate subsets of MX
> RemoteObject, but it still seems like duplication of effort.
>
well, I'm talking not abou
As long as Responders are PAYG and not baked into the basic RO implementation,
it is fine for others to try to replicate subsets of MX RemoteObject, but it
still seems like duplication of effort.
That said, I have not used RO or Responders in any real world application
myself. I'm not sure I u
Hi Piotr,
I think if I get some improvement over the current RO with Responders that
could go to develop. Other thing is I tried to make it work in mx RO.
People using Royale RO will benefit from it. If some day mx RO is ready, I
think we'll shift to mx RO, although royale RO could be continue to
Yes. Temporarily using a branch as a shim to keep working until a permanent
solution is available is something I’ve done more than once.
That’s the cost of working with bleeding edge… ;-)
Harbs
> On Oct 9, 2018, at 1:39 PM, Piotr Zarzycki wrote:
>
> Carlos,
>
> You can always use branch, mak
Carlos,
You can always use branch, make your changes and wait for the proper one
using branch. Some time ago Harbs did it the same as far as I remember.
There is no need to wait if you need something ASAP.
Thanks,
Piotr
wt., 9 paź 2018 o 12:36 Carlos Rovira napisał(a):
> Hi Alex,
>
> since the
Hi Alex,
since there's no planned ETA for anyone here (that I know), I could try at
some point to have a minimal Responder functionality in the current working
RO. Does not have sense to duplicate all the code but I think has sense to
see if some little changes can provide the minimal needs.
than
I think you'll have to wait until someone gets all of the old Flex RO code to
compile and run. I'm currently still debugging the compiler, so no way it will
be ready tomorrow.
It doesn't make sense to try to duplicate all of this code and get it to work
some other way.
-Alex
On 10/8/18, 3:2
Hi Alex,
I'm closing for today, but tomorrow I'll need to handle more than one
Responder for RemoteObject calls, so each operation/method can have it's
own responder and create methods for each one in my controllers. with the
current RemoteObject implementation could you share what could be the mo
Ok Alex, thanks, didn't know that you have this task to make it work RO. I
though you only try to compile it.
That's good to know. I'm trying right now to make a real world app and
since I don't have a micro structural IOC framework like Swiz, that was
that I use in Flex, I'm trying to structure an
I believe I already said I am working on RemoteObject.
The Flex compiler generates custom code for mx:RemoteObject. The Royale
Compiler currently does not. I am working on it.
Thanks,
-Alex
On 10/8/18, 3:13 AM, "Carlos Rovira" wrote:
Hi,
I was experimenting trying to get Remot
65 matches
Mail list logo
