Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I did two builds of one of my non-broken projects, for which the ONLY difference was changing includeNullChecks true to false, and comapred the two sets of sources for the xcode projects. There were a lot of curious differences in the pods project.pbxprod Maybe that's a clue to what the problem

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

This gets stranger. I revived my private build process, using current github sources, with includeNullChecks=false. It works fine, and at good speed, if I comment out the superfluous labels associated with the "statement expected" problem. There are currently 2 in my build. I'm entertaining

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

On Friday, September 1, 2017 at 2:14:34 PM UTC-7, Steve Hannah wrote: > > The actual static field name is added by javac, and the current version > (without adding _ENUM_) works with all of our tools, as far as I know. > Making the change you suggest would break everything. > > The question

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

The actual static field name is added by javac, and the current version (without adding _ENUM_) works with all of our tools, as far as I know. Making the change you suggest would break everything. The question is, why is your local toolchain generating these static fields with a different naming

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

This is the point where I found it necessary to add an ENUM to the code being generated in ByteCodeClass.java if (isEnum) { b.append("JAVA_OBJECT __VALUE_OF_").append(clsName).append("(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {\n"); b.append("

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I have now changed the default on this build hint to "true", pending further investigation on why it would be causing these problems. That change will be reflected in the next server update. Steve On Fri, Sep 1, 2017 at 10:17 AM, Dave Dyer wrote: > Yes, adding the

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

Yes, adding the hint fixed the build. On Friday, September 1, 2017 at 8:54:53 AM UTC-7, shannah wrote: > > If you add the build hint ios.includeNullChecks=true does that help? > > > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

If you add the build hint ios.includeNullChecks=true does that help? On Fri, Sep 1, 2017 at 8:47 AM, Dave Dyer wrote: > Todays update did not improve my situation.Builds are still much > slower than before, and time out. > > > > -- > You received this message

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

Todays update did not improve my situation.Builds are still much slower than before, and time out. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

That's troubling. I was sure this was resolved for you by now. Although that's probably unrelated to the current regression and more related to Daves problem as your app is pretty monolithic too. It's hard to tell if Dave's PR's will make a difference as building something can be fast locally

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I´m STILL unable to build IOS apps for like 3 months now, cause i´m constantly getting build timeout OR "Exception on appending to log: java.io.IOException: Stream closedFailed xcodebuild step" I need to send like 10 builds ( one build takes up to 25 minutes ) to get one successfull one.

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

@Nick we changed the signature of the method to reference TextArea instead of TextField. Update the client libs and send a new build to resolve that first error. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

On Monday, August 28, 2017 at 4:33:43 PM UTC-7, Steve Hannah wrote: > > The ParparVM source code also contains no results if you grep _ENUM_ . > That part is constructed by javac and propagated through. > This is in the code for "{enum}.values() which is wholly constructed by parpavm. --

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

On Monday, August 28, 2017 at 4:33:43 PM UTC-7, Steve Hannah wrote: > > The ParparVM source code also contains no results if you grep _ENUM_ . > That part is constructed by javac and propagated through. > Both sets of code were generated from the same client binaries, so there is no

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

The ParparVM source code also contains no results if you grep _ENUM_ . That part is constructed by javac and propagated through. On Mon, Aug 28, 2017 at 4:19 PM, Dave Dyer wrote: > > Nonetheless, right now it looks like nativeMethods.m does need to use a >> few

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

> Nonetheless, right now it looks like nativeMethods.m does need to use a > few things from CN1, and that's why the dependency is there. > The dependency is there, but the file is not, at least in my environment. As I said, I'm working in my own fork of the parpavm build code, updated from

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I can't do versioned builds. I have a fossil copy of the parpavm build process from the era when I proposed all the fixes that you haven't installed. The labels fix I'm referring to is in https://github.com/codenameone/CodenameOne/pull/2108 -- You received this message because you are

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

Dave, Another problem is this: > > nativeMethods.m:#include "CodenameOne_GLViewController.h" I agree that this probably doesn't belong in the nativeMethods.m file since nativeMethods.m is part of ParparVM and CodenameOne_GLViewController.h is part of CN1 --- ParparVM shouldn't depend on CN1.

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

Nick, Those two error reports look unrelated to each other. One is likely related to including a native lib that is built for 32 bit and the other is something else - perhaps a timeout. I looked in the issue tracker but can find no sign of an issue posted by you on either of these. If you do a

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

> Not sure how things are tested before being pushed live, but this kind of critical failure is causing serious consequences for me and my clients and it resulting in us > >evaluating other alternatives to Codename One so we can build locally and at least have some action that we can take when

[codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

The big problem for my build, probably the fatal one, is that last week's builds generated this code for enums JAVA_OBJECT __VALUE_OF_yspahan_YspahanConstants_ymisc(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) { JAVA_ARRAY values =

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

Another problem is this: nativeMethods.m:#include "CodenameOne_GLViewController.h" there is no longer a file with that name, and this is the only reference to it. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I can't send any iOS builds, the error log is different depending on the project: BluekeyInspect-dummy.o)) was built for newer iOS version (7.0) than being linked (6.0) Undefined symbols for architecture armv7: "_com_codename1_components_FloatingHint___INIT_com_codename1_ui_TextField",

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I'm trying this out with my local build setup, and one thing that is apparent is that the "expected statement" bug due to dangling labels at the end of methods is much more of a problem - those null checks which are now gone were creating a useful end-of-method padding. There's already a fix

Re: [codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

The recent change, which removes null checks from methods (and instead relies of signals), added an #ifdef macro to each method, which may have affected LLVM's compile performance. That's just speculation as past experience has taught me that LLVM can be ground to a halt by the strangest little

[codenameone-discussions] Re: IOS builds failing (timeout?) Aug 27

I saw another report for this. It might be a regression due to the new xcode changes e.g. the null check RFE. We need to look into that. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop