One other difference between the two builds looks strange, but I can't say
it's a problem. In the "check" case, the locals
generated for a method are all in order.
JAVA_INT
> online_tantrix_common_GameBoard_formForcedList___R_int(CODENAME_ONE_THREAD_STATE,
>
> JAVA_OBJECT __cn1ThisObject) {
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
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 th
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
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
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("JAVA_
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 hint fixed the build.
>
> On
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
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 because you are subscribed to
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
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
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.
-
@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 th
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.
--
Yo
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 possibili
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 things from CN1, and that's why t
> 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 gi
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 subscr
Hi Steve,
I'm also getting this error (as the entire error log) on 'Latest':
Exception on appending to log: java.io.IOException: Stream closed
If I send a 3.7 build it works but I need to strip out a couple of things
from my app that use new features.
Its frustrating because I've come back fr
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.
N
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
> 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
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 =
(JAVA_ARRAY)get_static_yspahan_YspahanConstants_ymisc
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 from
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",
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 for
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 th
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 receivin
28 matches
Mail list logo