Module build failed: ReferenceError: [BABEL] /app/src/index.js: Unknown option: /app/node_modules/react/react.js.Children

Do you want to request a feature or report a bug? report a bug.
I looked for the solution and everywhere it is suggested that babel-preset-react has to be added to the project. I have it, but still I get the same error:
Module build failed: ReferenceError: [BABEL] /app/src/index.js: Unknown option: /app/node_modules/react/react.js.Children

What is the current behavior? Compiling the code spits out error.
If the current behavior is a bug, please provide the steps to reproduce.
The  webpack configuration:
module.exports = {
  entry: [
    './src/index.js'
  ],
  output: {
    path: __dirname,
    publicPath: '/',
    filename: 'bundle.js'
  },
  module: {
    loaders: [{
      test: /\.js$/,
      exclude: /node_modules/,
      loader: 'babel-loader',
      query: {
        presets: ['react', 'es2015', 'stage-0']
      }
    }]
  },
  resolve: {
    extensions: ['.jsx', '.js']
  },
  devServer: {
    historyApiFallback: true,
    contentBase: './'
  }
};`
And the `.bablerc`:

`{
  "presets": ["react", "es2015", "stage-0"]
}

The index.js file content:
import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import { createStore, applyMiddleware } from 'redux';
import { BrowserRouter, Route, Switch } from 'react-router-dom';
import promise from 'redux-promise';
import reducers from './reducers';
import LoginForm from './components/login_form';

const createStoreWithMiddleware = applyMiddleware(promise)(createStore);

ReactDOM.render(
  <Provider store={createStoreWithMiddleware(reducers)}>
      <BrowserRouter>
        <div>
          <Route path="/" component={LoginForm} />
        </div>
      </BrowserRouter>
  </Provider>
  , document.querySelector('.container'));

I get the following error when I compile it on heroku:
2017-11-30T07:12:53.928690+00:00 app[web.1]: ERROR in ./src/index.js
2017-11-30T07:12:53.928692+00:00 app[web.1]: Module build failed: ReferenceError: [BABEL] /app/src/index.js: Unknown option: /app/node_modules/react/react.js.Children. Check out http://babeljs.io/docs/usage/options/ for more information about options.
2017-11-30T07:12:53.928692+00:00 app[web.1]:
2017-11-30T07:12:53.928693+00:00 app[web.1]: A common cause of this error is the presence of a configuration options object without the corresponding preset name. Example:
2017-11-30T07:12:53.928694+00:00 app[web.1]:
2017-11-30T07:12:53.928695+00:00 app[web.1]: Invalid:
2017-11-30T07:12:53.928696+00:00 app[web.1]:   `{ presets: [{option: value}] }`
2017-11-30T07:12:53.928696+00:00 app[web.1]: Valid:
2017-11-30T07:12:53.928697+00:00 app[web.1]:   `{ presets: [['presetName', {option: value}]] }`

What is the expected behavior? It should compile fine.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
I have the following dependencies in package.json:
{
  "main": "index.js",
  "engines": {
    "npm": "5.5.1",
    "node":"8.9.1"
  },
  "scripts": {
    "start": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js",
    "test": "mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test",
    "test:watch": "npm run test -- --watch"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.2",
    "babel-preset-es2015": "^6.1.18",
    "babel-preset-react": "^6.24.1",
    "babel-preset-stage-0": "^6.24.1",
    "chai": "^3.5.0",
    "chai-jquery": "^2.0.0",
    "jquery": "^2.2.1",
    "jsdom": "^8.1.0",
    "mocha": "^2.4.5",
    "react-addons-test-utils": "^0.14.7"
  },
  "dependencies": {
    "axios": "^0.17.1",
    "lodash": "^3.10.1",
    "react": "^0.14.3",
    "react-dom": "^0.14.3",
    "react-redux": "4.3.0",
    "react-router": "^2.0.1",
    "react-router-dom": "^4.0.0",
    "redux": "^3.0.4",
    "redux-form": "^6.6.3",
    "redux-promise": "^0.5.3",
    "validator": "^9.1.2",
    "webpack": "^3.8.1",
    "webpack-dev-server": "^2.9.4"
  }
}

Node version is 8.9.1

This is a babel issue. Report this issue to babel.

How do you say it is bable issue while it says there is something wrong in the babel-loader config ?


ICO Landing Page and Registry Database

I assume that users will want to provide more information about their tokens/crowdsales than can reasonably be stored on-chain. Ie, logos, whitepapers, etc. What are your thoughts on creating a TokenMint database?
(Premium feature? ;) )

Per slack discussion, let's do this. Need a good landing page template. Information format will look something like this: http://tokenmint.io/ico/0x59153bcf752b4e1ef294b370d635ce320bfdac08


Jenkins for Autobuild

Original issue: https://charm.cs.illinois.edu/redmine/issues/33

It would be very useful to have Jenkins integrated in with Autobuild.

Firing off automatic tests on a limited number of platforms per git push event would allow us to catch errors early.
The ability to schedule tests at a finer level of granularity would be helpful

Periodic (perhaps weekly) execution of SU consuming full tests on relevant platforms
Periodic execution of performance benchmarks
Periodic execution of flagship application tests

The definition of sets of tests to be run at various frequencies

Autobuild's current all or nothing approach discourages aggressive expansion of the test framework
Various parameter choices, such as varying PPN and the many command line options, all go untested

Original date: 2014-01-06 04:23:04

I fail to understand delay in completion of this task; increasing the priority. Please finish asap.

Original date: 2014-02-17 17:02:34

I just realized a challenge in our matrix build setup. We've lost the ability to specify per-configuration arguments and options. That covers the failure of several of the SMP builds and sort of ICC.

Original date: 2015-01-22 21:03:04

We've had automatic testing on push for a while now but we don't have the matrix build of all of our configurations working. IIRC, a subtask for the matrix has been assigned to Sol.

Closing this, we'll probably go with GitHub actions.


Model taxes?

It's not at all clear to me what assumptions, if any, are made about taxes now. Like, is the portfolio gain just pre-tax and I should include taxes under my spending plan? That's hard to do, since I don't know how much the realized gain is in a given year. It would be great if you could input assumptions about the capital gains tax rate.
(Maybe for most US retirees, cap gains will be small in retirement, but we are considering moving to a country with a flat 30% cap gains tax, so it will definitely matter there.)

The current implementation makes absolutely no tax assumptions. Everything is just pre-tax.
One of the other forks was looking at adding taxes, but it was adding US tax which was of no use to myself.
Considering how complex any individual countries tax system is, I have no idea how to model taxes in a generic way that would work for many countries.
It is not something I intend to work on, though if yourself or anyone else does add it (without making the interface too complicated), I would be happy to accept a pull request.


enhancement: clean pdf elements (bump unstructured-inference) <- Ingest test fixtures update

This pull request includes updated ingest test fixtures.
Please review and merge if appropriate.

Image's not handled correctly, closing


Redundant code in models.py

Hi, Miguel!
It seems that this line in models.User.add_self_follows is redundant:
class User():
    # ...
    @staticmethod
    def add_self_follows():
        for user in User.query.all():
            if not user.is_following(user):  # <------- this line
                user.follow(user)
                db.session.add(user)
                db.session.commit()

Since it already check in User.follow():
 class User():
   #  ...
    def follow(self, user):
        if not self.is_following(user):  # <----------
            f = Follow(follower=self, followed=user)
            db.session.add(f)

Yes, good catch. I'll make a correction. Thanks!

:smile:


Add file-predicate example

This is to solve #125
Happy to tweak this with any reviews, comments and ideas :smiley:

Thanks! Could you check why the build is failing?

I think I know why it didn't build. Fixing it.

Tests passed. I'm wondering if using unwrap() is good style or if I should do it differently.
Whatever you prefer @dtolnay

Unwrap is not good style. Check out a note about error handling.

Gotcha. Cleaning it now.

Nicely done!


Update Shallow End and Clubhouse links

Issue: Current link to Stuck in the Shallow End and current link to Unlocking the Clubhouse: Women in Computing leads to a "Book not found..." page.

Working link to Shallow End: https://mitpress.mit.edu/9780262514040/stuck-in-the-shallow-end/
Working link to Unlocking the Clubhouse: https://mitpress.mit.edu/9780262632690/unlocking-the-clubhouse/

Fixed, thanks for reporting.


Should we allow mysql json field as datatypes.JSON

type Bill struct {
	ID              int32     `gorm:"column:id;type:int(10) unsigned;primaryKey;autoIncrement:true" json:"id"`
	Detail        string ->  datatypes.JSON    `gorm:"column:detail;type:json" json:"detail"`
}

in some cases, we have already defined the field as type JSON, gen gorm also have gorm.io/datatypes to support it.
but when code was generated by go-gorm/gen it will define all type:json field as string

u may try this https://github.com/go-gorm/gen#data-mapping


Redux state is not updated Issue. But redux logger shows the correct action and next state update

Hi,
I am using Redux for my web application. State has to be updated after user login. Redux logger is used for debugging. Everything is fine in redux logger but state is not updated. Please give any idea about this issue.
Reducers:
import { adminConstants } from '../Admin/admin.constants.js';

export function adminReducers(state={},action)
{
  switch (action.type) {
    case adminConstants.ADMIN_LOGIN_REQUEST:
      return {
        loggingIn: true,
        };
    case adminConstants.ADMIN_LOGIN_SUCCESS:
      return {
          loggedIn: true,
          admin:action.admin
      };
    case adminConstants.ADMIN_LOGIN_FAILURE:
      return {};
    case adminConstants.ADMIN_LOGOUT:
      return {};
    default:
      return state;
    }
}

CombineReducer:
const rootReducer = combineReducers({
  authentication,
  registration,
  users,
  alert,
  adminReducers
});

export default rootReducer;

mapStateToProps: (In this console.log shows empty for all objects)
function mapStateToProps(state) {
    console.log("state "+ JSON.stringify(state));

    const {  adminReducers } = state;
    const { admin } = adminReducers;
    return {
           admin
    };
}
const connectedAdminPanel = connect(mapStateToProps)(AdminPanel);
export { connectedAdminPanel as AdminPanel };

Accessing state in after login page, but shows empty for adminReducers:

Redux logger: (show that adminReducers in state is updated)

Action dispatch:
function login(adminname, password) {
    return dispatch => {
        dispatch(request({ adminname }));

        adminService.login(adminname, password)
            .then(
                admin => {

                    dispatch(success(admin));
                    console.log("Admin ok");
                    //window.location='/admin/panel';
                },
                error => {
                    dispatch(failure(error.toString()));
                    dispatch(alertActions.error(error.toString()));
                }
            );
    };

    function request(admin) { return { type: adminConstants.ADMIN_LOGIN_REQUEST, admin } }
    function success(admin) { return { type: adminConstants.ADMIN_LOGIN_SUCCESS, admin } }
    function failure(error) { return { type: adminConstants.ADMIN_LOGIN_FAILURE, error } }
}

store creation:
const loggerMiddleware = createLogger();

export const store = createStore(
    rootReducer,
    applyMiddleware(
        thunkMiddleware,
        loggerMiddleware
    )
);

Please help me
No response from stackoverflow.

This is a bug tracker, not a support system. For usage questions, please use Stack Overflow or Reactiflux where there are a lot more people ready to help you out - you'll probably get a better answer faster. Thanks!


runtime: drop support for linux/armv5E and linux/armv6

Since the introduction of Linux/ARM support, the minimum required
hardware to run Go with Linux was ARMv5E, e.g.ARM926.
At that time, this choice makes sense because ARM9 systems are
still around, and we even had an ARMv5E builder for some time.
However, ARMv5E lacks some important atomic instruction support.
LDREX/STREX is introduced in ARMv6 (ARM11), and
LDREXB/STREXB, LDREXH/STREXH, LDREXD/STREXD are introduced
in ARMv6K. Without these instructions, we resort to emulating the
required 64-bit atomic operation using 57 spinlocks selected by address
(which uses mod and is a slow operation on ARM) [see https://tip.golang.org/src/runtime/internal/atomic/atomic_arm.go]
I don't know how many projects out there that still uses ARMv5E and
Go, but I don't expect many. I propose to increase the minimum
architectural requirement to ARMv6 (and possibly ARMv6K), so that
at least we can use LDREX/STREX, which should help a lot with the
new atomic-heavy runtime.
To summarize the benefits,

if we raise requirement to ARMv6, then we can intrinsicify 32-bit atomics.
if we raise requirement to ARMv6K, then in addition to 1, we no long can
remove the emulated 64-bit atomics from runtime by using the native
LDREXD/STREXD instructions, but also intrinsicify them in the compiler
like other ports. We can also use YIELD instruction to address #16663.

If you still use Go on ARMv5E systems, please help by listing the processor
model used. Thanks.
PS: other supported OSes do require ARMv6K as only Linux provides
required 64-bit cas kernel helper for sync/atomic. Another way to go
is to modify the runtime/internal/atomic package to:

use LDREXD/STREXD on non-linux,
use kernel cas64 on linux.
But this solution will complicate maintaining the code and as we don't
have a real ARMv5E builder, I think the support is certainly going to
bitrot.

PS2: The core used by Raspberry Pi 1, ARM1176JZF-S, is ARMv6K,
so this proposal won't affect Raspberry Pi 1, the most popular ARMv6
systems.

/cc @cherrymui @davecheney @josharian

@hasty

I'm fine with this.
On Tue, Sep 13, 2016 at 10:31 AM, Josh Bleecher Snyder <
<EMAIL_ADDRESS>wrote:

@hasty https://github.com/hasty
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-246537987, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_pdNkUCP-Uhku-pBXNnA4Z7NqSgks5qpe7ogaJpZM4J7K4x
.

SGTM

SGTM, especially if it means I can kill the not-really-ARM5 linux-arm-arm5 builders.

To be precise, do you support only removing armv5 support or also requiring
armv6k (RPI 1 won't be affected)?

Killing the linux-arm5 builder also requires us to drop GOARM=5 support,
which is also used (overloaded) to mean FPU-less ARM CPUs (which does not
necessarily mean ARMv5. Yes, this is very confusing.)

I know close to zero about the dozens of flavors of ARM but if all Raspberry Pis still work I find it hard to object to requiring ARMv6K if that makes things easier.

Thanks, @josharian
No objections here; we've moved on to ARMv7A.

I understood your request to be "remove GOARM=5", and I agree with that.
On Tue, Sep 13, 2016 at 12:22 PM, Minux Ma<EMAIL_ADDRESS>wrote:

Killing the linux-arm5 builder also requires us to drop GOARM=5 support,
which is also used (overloaded) to mean FPU-less ARM CPUs (which does not
necessarily mean ARMv5. Yes, this is very confusing.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-246554244, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA9xGsaStiiuyeGF20NGifk9ZzWm6ks5qpgjKgaJpZM4J7K4x
.

The Atmel SAM9G25 SOC looks like it may be a victim of this feature request.  It implements the ARM architecture version 5TEJ instruction set.  Products like the Arietta G25 from ACME systems (which I use) will become incompatible with future versions of the GO ARM runtime if what I'm reading here is correct.
While I generally agree with what is proposed here for GO 1.8, is there no way for a developer to re-introduce a V5-compatible runtime into his/her own GO development environment?
If the architecture requirement gets bumped to ARMv6 or 6K, how long will that be good for?
-Pete

The main goal for this proposal is to bump the minimum ARM requirement to
ARMv6K
so that we can use native 8-bit/32-bit/64-bit LDREX/STREX instructions and
inline
them in the program. (As explained in the proposal, we currently use
emulated 64-bit
atomic operations in the runtime.)
Once we drop the support for v5E and v6 (without K), it will be pretty hard
to regain
the support because it's not a master of re-introduce necessary runtime
functions.
One difficulty for maintaining ARMv5E and ARMv6 support is that, it's
really hard
to find systems with enough memory to host a Go builder (we need at least
512MB,
preferably 1GB)
Dropping support for ARMv5E mainly affect various ARM926 systems, and
dropping
support for ARMv6 mainly affects various ARM1136 and ARM1156 based SoCs
(one notable example iMX3x series, used in earlier Kindle eReaders.)
There are only two ARM11-series processors that implements ARMv6K: ARM1176
and ARM11MPCore. The other two ARM1136 and ARM1156 doesn't implement
the required 8/64-bit LDREX/STREX instruction.
We could consider just dropping ARMv5E support, and then see if we can
reduce
the use of 64-bit atomic operations in the runtime. @aclements, are 64-bit
atomic
operations critical for runtime performance on 32-bit systems? If not, I
think we can
just drop ARMv5E support for Go 1.8 in order to continue support ARM11
processors.

@aclements, are 64-bit atomic operations critical for runtime performance on 32-bit systems?

It's hard to guess, but I don't think so. I took a quick look through all of the 64-bit atomic operations and we're pretty careful to amortize the cost of almost all of them. It might worth turning gcController.dedicatedMarkWorkersNeeded and gcController.fractionalMarkWorkersNeeded into int32s, since those can get hit on every scheduling decision during GC, but those are also perfectly fine as int32s (I think I just made them int64s because we don't have atomic ops on int32).

We should probably do some more research to find people who might be using these chips. @minux, do you want to mail golang-nuts? Failing any pushback, this sounds like it's a go.

Minux, did you email golang-nuts?

I see no email to golang-nuts. I am happy to send one. I may ask about OS X 10.8 at the same time.
@minux, is there an easy command to run on Linux systems to find out whether they'd be affected?
Thanks.

Ping @minux.  If so, time is running out.

I think we can revisit this in the next cycle because the tree is frozen
so there won't be any change that would benefit from this.
The test, at least on glibc linux/arm system, is this:
LD_SHOW_AUXV=1 ls | grep AT_PLATFORM
(the ls command can be replaced with any dynamic linked program)
And if the output says:
AT_PLATFORM:     v6l
or v7l, then the system won't be affected. If its v5l, then it will be
affected.

I think deleting code & updating docs is okay for the freeze if you want to proceed for Go 1.8.

The real benefit of removing armv5e support is intrinsicify
32-bit atomics.
removing the support itself won't delete much code though.
(we still need the softfloat implementation for mips.)

I just verified that rpi1 supports the yield instruction
in the ARM mode, therefore, if we raise the minimum
arm architecture requirement to armv6k, then we can
address #16663 as well.

Fixing #16663 is probably Go 1.9 material.
But I'd be happy with Go 1.8 breaking armv5 enough what we could remove the fake builders, add some docs to the Go 1.8 release notes, and simplify our lives going forward in Go 1.9.

OK, how about this:
In Go 1.8 release note, we will announce the intention to drop
(at least) ARMv5E support in the next release.
I did a survey of how other project deprecates support for
systems, it seems some notable projects (e.g. gcc) do
announcements in the immediate preceding release first.

SGTM
On Wed, 9 Nov 2016, 17:50 Minux Ma<EMAIL_ADDRESS>wrote:

OK, how about this:
In Go 1.8 release note, we will announce the intention to drop
(at least) ARMv5E support in the next release.
I did a survey of how other project deprecates support for
systems, it seems some notable projects (e.g. gcc) do
announcements in the immediate preceding release first.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-259345313, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_ijMYvn_elwtvxYEe0SGC5k9DOkks5q8W0-gaJpZM4J7K4x
.

How about we just drop it for Go 1.8?

Specifically, how about we make Go 1.8 require ARMv6K (what Raspberry Pi 1 has)?

LGTM.
On Tue, 15 Nov 2016, 08:16 Russ Cox<EMAIL_ADDRESS>wrote:

Specifically, how about we make Go 1.8 require ARMv6K (what Raspberry Pi 1
has)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-260465108, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA3Ts-z6Rv-7C9WMgE_SylBbpdhl-ks5q-M-pgaJpZM4J7K4x
.

Is this comment still true?
(https://go.googlesource.com/go/+/4ca3a8f7a807bba55e9db82b9aa8c43b1a186b8e/src/cmd/dist/util.go#530)
	if goos == "freebsd" || goos == "openbsd" {
		// FreeBSD has broken VFP support.
		// OpenBSD currently only supports softfloat.
		return "5"
	}

@cherrymui, I believe that is a different "ARM 5". We're not talking about dropping software floats. See Minux's comments above, in particular:

Killing the linux-arm5 builder also requires us to drop GOARM=5 support, which is also used (overloaded) to mean FPU-less ARM CPUs (which does not necessarily mean ARMv5. Yes, this is very confusing.)

The messaging here needs to be very clear.

Thanks. Then, are we going to do anything in the runtime or build tools to stop GOARM=5 program from building/running?

My understanding is that this bug is about retiring some very old arm hardware but not to the point of requiring VFP in hardware and so not about retiring GOARM=5.

I still suggest we announce our plan to drop support for armv5 and armv6
for 1.9 and continue to support them for 1.8 to give existing users some
time to upgrade.
The other reason is that there won't be much benefit of dropping support
during the code freeze.

Regarding FreeBSD VFP support, last time I checked they don't implement VFP
support routines to correctly handle denormals (some VFP implementations
rely on software feedback to support denormals.)
We could try GOARM=6 on Raspberry Pi 1 with latest FreeBSD and see if the
math package tests pass. If it could, we can remove the forced GOARM=5 for
FreeBSD.

The problem was the vfp detection in cmd/dist would crash the kernel on
freebsd/arm systems (this was close to two years ago, the situation may
have changed now), setting GOARM=5 avoided the crash during bootstrap.
On Fri, Nov 18, 2016 at 10:10 AM, Minux Ma<EMAIL_ADDRESS>wrote:

Regarding FreeBSD VFP support, last time I checked they don't implement VFP
support routines to correctly handle denormals (some VFP implementations
rely on software feedback to support denormals.)
We could try GOARM=6 on Raspberry Pi 1 with latest FreeBSD and see if the
math package tests pass. If it could, we can remove the forced GOARM=5 for
FreeBSD.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-261399554, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA5dLeuXYcvnM_ez7LYCotQfvV_tFks5q_N74gaJpZM4J7K4x
.

We've got two requests for continuing ARMv5 support so far.
https://groups.google.com/forum/#!topic/golang-dev/CO15hgslZ0o
https://groups.google.com/d/msg/golang-dev/lWL6L9-DejU/4ybgle4bCgAJ
There will always be ARMv5 hardware in service, like there are still
Windows 2000 in service. Yet we've dropped support for the latter.
we need to set a clear criteria for retaining ARMv5 support. My
proposal is that we need to have a real linux/armv5e builder to retain
the support. With a little swap and a lowered GOGC, even 256MB
RAM could complete all.bash (using tip to bootstrap), so the builder
requirement is not that hard to meet for an ARMv5 machine anymore.

As I mentioned in the thread but saving for posterity here, Space Monkey is more than happy to provide all of the internet connected 256MB Feroceon ARMv5TE internet connected builders with swap you need.

Mender chose Go because of its strong embedded support. It seems premature to drop support for ARMv5 if Go is serious about the IoT space, even if ARMv5 is not the most common.

@OrangeTux

for how long will Go support the hardware it currently supports? Does Go have a policy around this topic?

So, in theory, if go1.8 is the last version that supports architecture X, you should expect bug fixes for that architecture to stop being pushed as soon as go1.9 is out (go1.10 for security issues).

Apologies for not seeing this sooner, and with full respect and acceptance of Go dev team members decision.
Go was used for hobby and school robotics projects on Lego EV3  platform, which uses ARM926EJ-S, and has 64MB RAM (https://en.wikipedia.org/wiki/Lego_Mindstorms_EV3), on top of ev3dev (http://www.ev3dev.org/)
There are a number of projects on github, in various states of (non)maintenance  which use Go to develop for EV3 (https://github.com/search?utf8=✓&q=ev3+language%3Ago)
I believe in most cases the compilation was done on another (linux x86_64) system, for GOARM=5 GOARCH=arm target.

I agree with @minux.
There are concrete disadvantages to ongoing support for ARMv5, beyond simply the maintenance burden. For instance, the runtime enjoys intrinsic atomics on many architectures, but not arm, precisely because Go supports ARM architectures without the modern SMP extensions. (The same is true for a couple other low-level details, like byte-swapping, which are made easier with v7 and older v6 cpus.)
For as long as gc eschews compiler target flags (I'm agnostic on that point, FWIW), there will be a greater disadvantage to supporting older platforms than there would be for, say, gcc, because the compiler will always have to target the lowest common denominator of hardware capabilities. That's the price we're all paying for toolchain simplicity.
Just my two cents.

Maybe more trouble than it's worth, but:
What about copy/pasting GOARCH=arm into two halves, GOARCH=arm (which an evolve to assume modern stuff) and GOARCH=arm5 (which can receive minimal ongoing love, and get simplified in the process, assigning GOARM=5)
I feel like that's been discussed in the past. Is it time to revisit it?

I'd expand on the reason why the current ARM backend only targets the
lowest common denominator.
It all has to do with the real meaning of $GOARM. As far as the
compiler and docs (https://golang.org/doc/install/source) are concerned,
GOARM value only select the FPU status (5=softfloat, 6=VFPv1, 7=VFPv3),
not ARM architecture versions as most people would expect.
Therefore, the compiler is forced to generate the same code (really the
same code, GOARM=5 is supported by cmd/internal/obj inserting a call
to softfloat emulation routine before a sequence of floating point
instructions)
for all three values of GOARM.
We made a mistake when defining GOARM: VFP status and ARM architecture
version really are two separate property. For example, ARMv5E chips could
also have FPU (at least in theory) and there are ARMv6 chips without VFP.
To continue supporting ARMv5/6 and also bring optimizations enjoyed
by other architectures to ARMv7, we need to define a clear way to specify
ARM architecture versions, independent of the VFP status, for the compiler.

If arm were split into two back-ends, I'd argue that aarch32 should be its
own architecture, since it's what the ARMv8 chips implement for 32-bit
mode, and it's likely to be what most of the new 32-bit designs implement
going forward. (Critically, it promises vfpv4 and NEON, which would mean
that any of those instructions could safely be generated.) One hopes that
it will have better longevity than prior versions, since it's likely to be
the last 32-bit arm architecture with the 'A' suffix.
On Thu, Jan 5, 2017 at 5:08 PM, Minux Ma<EMAIL_ADDRESS>wrote:

I'd expand on the reason why the current ARM backend only targets the
lowest common denominator.
It all has to do with the real meaning of $GOARM. As far as the
compiler and docs (https://golang.org/doc/install/source) are concerned,
GOARM value only select the FPU status (5=softfloat, 6=VFPv1, 7=VFPv3),
not ARM architecture versions as most people would expect.
Therefore, the compiler is forced to generate the same code (really the
same code, GOARM=5 is supported by cmd/internal/obj inserting a call
to softfloat emulation routine before a sequence of floating point
instructions)
for all three values of GOARM.
We made a mistake when defining GOARM: VFP status and ARM architecture
version really are two separate property. For example, ARMv5E chips could
also have FPU (at least in theory) and there are ARMv6 chips without VFP.
To continue supporting ARMv5/6 and also bring optimizations enjoyed
by other architectures to ARMv7, we need to define a clear way to specify
ARM architecture versions, independent of the VFP status, for the compiler.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-270804305, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACzf5uO_t76DBLrm3Ybwdsl5bResOFfUks5rPZQWgaJpZM4J7K4x
.

Sorry for responding so late, but the company I work for designs and manufactures IP-cameras for surveillance purposes. Some of those are still ARM5 based and it would be a really sad day for us if Go wouldn't be supported on them anymore.
Having Go running on them opens up the possibility for us to have the same code base for all of our products. This is a big win for us.

And we are of course also willing to donate hardware for building if that is a problem.

Please note that what's proposed here is for future Go versions to
drop support for ARMv5/v6. ARMv5/v6 users can of course continue
to use Go 1.8.
I don't think it's that big a deal because I doubt users of ARMv5 use
the most recent version of gcc or linux kernel. But why do you insist
on using the latest Go version? Are you really using the latest Go
version for your ARMv5/v6 products? As Go 1.8 will receive security
updates until at least Feb 2018. Are you still planning to produce and
maintain ARMv5/6 hardware in Feb 2018?
(I'm speaking from practical product management prospective: usually,
when a product is released, version for all used software will be frozen
unless critical security vulnerability warrants a upgrade.)

I don't think it's that big a deal because I doubt users of ARMv5 use the most recent version of gcc or linux kernel. But why do you insist on using the latest Go version? Are you really using the latest Go version for your ARMv5/v6 products?

We have a mechanism put into place where we can update part of the software running in the device without flashing a complete firmware. The kernel and compiler might be old, but the beauty of Go is that all the applications we install in the devices can be built with the same toolchain from exactly the same codebase regardless of CPU. Removing support for one of the CPU:s would force us to have a different branch for older products (when Go and its library moves forward), something we have managed to avoid up until now. This is of course not a complete show stopper, but it would probably complicate things for us.

As Go 1.8 will receive security updates until at least Feb 2018. Are you still planning to produce and maintain ARMv5/6 hardware in Feb 2018?

Most certainly supporting. Some of the products we support are several years old. New low cost products might also happen. It all depends on the cost/performance. We are currently using all kinds of ARM:s and also MIPS32.

Still I understand you reasons, and if it is hard to generate better code for newer CPU:s while still supporting ARM5, it probably has to go.

Removing support for one of the CPU:s would force us to have a different branch for older products (when Go and its library moves forward), something we have managed to avoid up until now. This is of course not a complete show stopper, but it would probably complicate things for us.

Space Monkey is in the same boat.

My company has been manufacturing ARM926 based industrial control systems with a specialized Linux based C++ application ~ 1k/yr for > 10 yrs and in 2017 will move to a fresh armv7 based hardware.
As our customer expects new applications to run on the old hardware, our migration plan of using Go heavily depends on Go providing armv5 support at least for next 4-5 years ...
I can probably live with using Go 1.8 for following years after the release of Go 1.9, provided the libraries we use stay sufficiently backwards compatible, hoping this will not hit us too hard when Go 2.0 comes out.
But wouldn't it be a cleaner solution to somehow fix the GOARM flaw, so that also other arm variants (Cortex-M, ...) could be more specifically targeted?

In the same boat. We deployed hundreds of IoT gateways accross Africa with ARM5 and at least 3 years support.
Hardware in IOT can't be upgraded easily, software yes.
Any serious IOT provider will think two times before puting trust in golang if this kind of decision appends.
Please reconsider this option.

Thank you to everyone who commented. I understand your concerns but want to highlight one thing from earlier in the thread.
We need reliable ARMv5 builders. Without them, even if Go technically says it supports ARMv5, but is untested, what is the point?
Several people have offered to setup builders, so now is the time to step up and get those builders online.
Thanks
Dave

Just leaving it here. One more person concerned about this: https://news.ycombinator.com/item?id=13369857

@renannprado I don't think there is any confusion about the concern this proposal has raised.
I ran the ARMv5 builder for three years until it became impossible to find a piece of real ARMv5 hardware that was both reliable enough and had enough memory to run the build successfully.
The issue at hand, in my mind, is the lack of a builder for ARMv5. What I want people watching this thread to do is continue to focus on this part of the problem.
Without a working ARMv5 builder, in my mind, the ARMv5 port is already dead

Oh, sorry @davecheney , I didn't realize I had dropped the ball here. When @bradfitz had asked if we could provide builders on the mailing list, I assumed that was one factor into this decision. I have just been waiting to hear a go-ahead - seemed silly to set up a bunch of builders if ARMv5 support is dropped anyway. Further, based on the conversation on the mailing list (https://groups.google.com/forum/#!topic/golang-dev/CO15hgslZ0o), it sounded like the build system or tests might require some small changes to work on our specific ARMv5 boards, but maybe that was a misread.
If the Go team is actually just waiting for ARMv5 builders, is https://github.com/golang/go/wiki/DashboardBuilders still the right instructions to follow? If a Go Team member can get me a builder hash I'll set it up.

@jtolds I'm not sure how my company could help. But if you need help don't hesitate to ask.

Same thing here. Our ARM5 based cameras only have a small amount of memory (I think typically 256MB). But if there is anything else we can do (e.g buying better suited hardware - if it exists?), don't hesitate to ask us too and I will speak to my manager.

@jtolds, how many do you have available to dedicate to the cause? How long does all.bash take on one of them? Do you have good network connectivity for them? I'd prefer to shard the tests over multiple, but that requires the new-style builders and better connectivity.

Realistically we have dozens of reliable builders but we could get more. Maybe low hundreds. They do have good network connectivity, but I'll get back to you shortly with all.bash timing.

Alright. I don't have exact timing for just the build step, but it took around 53 minutes for the compilation phase of go 1.7.4 sources on armv5.
The full all.bash took:
real    152m46.856s
user    70m29.980s
sys     2m47.020s

Not all the tests passed! Here's the output of the test phase: https://gist.github.com/jtolds/9d1c0618b896b940cc86d597296329dc

This was using a slow 5400 RPM drive - we can definitely speed this up by using an SSD. Notably, the compilation of bootstrap/compile/internal/gc took a very long time, maybe something like 10-20 minutes by itself? I assume the SSD would help swap performance the most.
Is this in the right order of magnitude? If so, I'll put an SSD in and rerun.

Well, normally decent machines can run all the tests in like 15 minutes. But our existing ARM builders can do ARM5 mode in like an hour. 152m seems, uh, much slower. But whatever.
Try setting GO_TEST_TIMEOUT_SCALE to, say, 3 or 5 to increase timeouts.
For the time failure: which distro/version are you running? Maybe your tzdata is stale. Or, what version of Go did you build at? Is that master?
SSD would help. tmpfs would help even more, but you probably don't have the RAM.

The TestLoadFixed failure is expected and the math/big timeout not very surprising..

Why is TestLoadFixed expected? Wasn't it fixed?
As for math/big and others: I think we skip or massively shorten a few of the tests on our existing "arm5" (not really arm5) builders.

Notably, the compilation of bootstrap/compile/internal/gc took a very long time

Could you try bootstrapping from tip or 1.8 beta/rc? The SSA compiler could make it much faster (it made a huge difference on my Raspberry Pi).

@bradfitz he's running go1.7.4, that's not fixed there.

Sorry for the lack of communication today (busy day) but I just kicked off 1.8 RC1's all.bash. I'll report back in the morning when I'm awake and it's done.

On Thu, Jan 12, 2017 at 1:55 PM, JT Olds<EMAIL_ADDRESS>wrote:

Alright. I don't have exact timing for just the build step, but it took
around 53 minutes for the compilation phase of go 1.7.4 sources on armv5.
The full all.bash took:
real    152m46.856s
user    70m29.980s
sys     2m47.020s
Not all the tests passed! Here's the output of the test phase:
https://gist.github.com/jtolds/9d1c0618b896b940cc86d597296329dc

If it takes 152 minutes to run make.bash and the std tests, I expect the
full all.bash
will take twice that time.
There are a few things that could help though:

use zswap and then hard disk/SSD backed swap
use a smaller GOGC value, like 10. But please note that small GOGC value
like 10 trade CPU for memory very aggressively. Usually, with small amount
of zswap, GOGC=25 can pass all.bash on a machine with 256MB memory.
use tip to bootstrap, instead of Go 1.4.  Go tip has much better GC and
memory consumption is also lower.
patch cmd/dist so that it only runs one command at a time (change "var
maxbg = 4" line in cmd/dist/util.go)

Please try these tips first before changing disks.
I've been able to run all.bash with only 256MB memory and almost no swap
usage with this setup.

My run last night (using Go 1.4 to bootstrap) took 230m, but had some cgo issues which should now be fixed.
zswap got merged in 3.11, and unfortunately I'm on a 3.10 kernel. I could get a newer kernel, but I'll attempt without that change for now.
Running with GO_TEST_TIMEOUT_SCALE=5 GOGC=20 GOROOT_BOOTSTRAP=/root/gobuild/go-tip and after having changed cmd/dist. My schedule is very swamped again today so I probably won't be able to report back until late tonight. I'll let you know! Thanks for all the help!

ALL TESTS PASSED

---
Installed Go for linux/arm in /root/gobuild/go-tip
Installed commands in /root/gobuild/go-tip/bin
*** You need to add /root/gobuild/go-tip/bin to your PATH.

real    324m21.381s
user    258m58.760s
sys     8m40.640s
root@spacemonkey:~/gobuild/go-tip/src# env|grep GO
GO_TEST_TIMEOUT_SCALE=5
GOROOT_BOOTSTRAP=/root/gobuild/go-tip-built/
GOGC=20

So, unless this is still just way off, I think I'll attempt to get a zswap-supporting kernel, some SSDs, and if parallelism helps, a stack of 20 of these or so. Sound alright?

Haven't done zswap yet but with an SSD for swap:

real    298m44.313s
user    263m36.300s
sys     8m4.120s

Going to try and back off on GOGC and increase cmd/dist's maxbg and see if it goes faster.

Using default GOGC is much better:
ALL TESTS PASSED

real    167m18.671s
user    142m44.710s
sys     7m48.490s

Okay, what do I need to do to hook these up?

@jtolds Thanks for putting effort in this.

As this proposal is accepted, the runtime library will support from ARMv6. But how should the generated assembly of the compiler be? It should support only ARMv6 instructions? Or if some ARMv7 instructions (such as the RBIT instruction which can benefit the CTZ intermediate operator) can be used if GOARM=7 is specified?
I suggest use the GOARM env-var and 6 is its default value. And ARMv7 users can benefit by specifying it to 7.

The core used by Raspberry Pi 1, ARM1176JZF-S, is ARMv6K,
so this proposal won't affect Raspberry Pi 1, the most popular ARMv6
systems.
When I first heard about abandoning ARMv6 thought that I lose the ability to use Go on the Raspberry Pi Zero. But now I can sleep peacefully.

As this proposal is accepted, the runtime library will support from ARMv6.

I hope we can reopen that! I'm ready to start some ARMv5 builders. Just need the creds.

Without a working ARMv5 builder, in my mind, the ARMv5 port is already dead.

I'm just curious. So now that jtolds has done the excellent job of providing us with ARMv5 builders, does this change anything?

For creds, please email bradfitz (at the obvious Go domain) to request a
linux/arm builder key. Thanks.

So, what's the story here? Are we not dropping this for Go 1.9 or not?
It sounds like we can get real builders, which moves my position away from killing arm5 back towards neutral or maybe even keeping it. What do others feel? Sounds like 3 or 4 companies are interested it in it remaining. I don't know how much work it is to keep it in place.
/cc @minux @cherrymui @rsc @randall77 @mdempsky @josharian

My 2c, which should not be given much weight, is: Given the responses in this issue, we should keep ARMv5, iff the real builders prove to be reliable (good uptime, reasonably latency, etc).

Please keep in mind that despite ARMv5 being already old, it is not yet dead!
It once came as ARM926ES-J, XScale, Feroceon, ... and is still actively being sold by Atmel, TI, NXP, Digi and more. Well-known devices include the above mentioned  SAM9xxx from Atmel and former Freescale's i.MX23..28, all very common in the field of industrial automation with large numbers, think e.g. of Lego EV3 which has Ti AM1808 ARM9.
Many less well-known chip manufacturers like e.g. Netsilicon/Digi are still producing their own ARM9 derivatives (with Linux support) for niche markets like telecom in remarkable numbers, without making fuzz.
What many of these platforms today have in common, is the scenario i already mentioned above:
Software development for the successors of these hardware veterans starts now,
and we would love to use Go (instead of C or C++) for it.
Now usually in these (often industrial) applications we have 10000's of ARMv5 devices in the field, which the customer expects us to maintain for the next 5 or so years, so if we cannot run at least a limited version of the new application on the old hardware, Go is a no-go and we are forced to stick with C++ to make the customer happy.
Thus we are already really happy about Go 1.8 still supporting ARMv5, opening at least the option of sticking at 1.8 for this hardware version, although I'm not sure if then it is worth the risk.
Unfortunately all our ARMv5 systems here have only ≤ 64MB of RAM, but
given @jtolds ' builder fulfills the expectations, please consider it useful to make ARM code generation generally flexible enough to make it simple to keep ARMv5 as lowest-end family member.

I support @ThomasKurz as my company also uses the same specs . and we would love to use Go for our applications. Hope you will consider our side.

Thus we are already really happy about Go 1.8 still supporting ARMv5, opening at least the option of sticking at 1.8 for this hardware version, although I'm not sure if then it is worth the risk.

@ThomasKurz Please note that maintaining a 1.8 based solution for five years is only possible if Go 1.8 is going to receive security patches for at least the same amount of time. Previously I have heard "until at least Feb 2018", but without an increased time scope for the security patches, that will leave us stranded anyway.

The support cycle for previous releases is listed here,
https://github.com/golang/go/wiki/Go-Release-Cycle, in the section marked
"Release Maintenance"
On Tue, 14 Feb 2017, 00:43 janflyborg<EMAIL_ADDRESS>wrote:

Thus we are already really happy about Go 1.8 still supporting ARMv5,
opening at least the option of sticking at 1.8 for this hardware version,
although I'm not sure if then it is worth the risk.
@ThomasKurz https://github.com/ThomasKurz Please note that maintaining
a 1.8 based solution for five years is only possible if Go 1.8 is going to
receive security patches for at least the same amount of time. Previously I
have heard "until at least Feb 2018", but without an increased time scope
for the security patches, that will leave us stranded anyway.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-279395636, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_lFH4lcvyzzzjCuGAQl4TTPOxQJks5rcF3vgaJpZM4J7K4x
.

So this means that Go 1.8 will receive security patches up until August 1 2018? That is still far away from the five years that @ThomasKurz needs to be able to support his customers and the company I work for has exactly the same problem.

That is still far away from the five years that @ThomasKurz needs to be able to support his customers and the company I work for has exactly the same problem.

Fortunately you have customers paying you money, so you can use that money to pay people to support Go 1.8 longer than we're supporting it for free. We just don't have the resources to support all old branches for years.

Tentatively tossing back into the proposal pile for further discussion. It would be nice to figure out the general policy for architectures; see also the thread on golang-dev about big-endian power5 ppc64.

Fortunately you have customers paying you money, so you can use that money to pay people to support Go 1.8 longer than we're supporting it for free. We just don't have the resources to support all old branches for years.

@bradfitz Has anyone talked about "supporting all old branches for years"? My remark was only about Go 1.8, which will be the last release that supports a very commonly used CPU (if this proposal is accepted).
The purpose of my posting was just to emphasize that if you are having an existing solution based on ARMv5, it is not an alternative to just freeze your code base at Go 1.8 (since it will not receive any security updates 1.5 year from now).
If it could only be arranged for Go 1.8 to receive crucial updates for a longer time period than normal, then I don't think anyone would have any problems with this proposal at all.

@janflyborg, we are going to support Go 1.8 for one year. We will support no branch for more than that. Certainly not five.
Like I said before, if you have revenue and are promising support to users, you need to budget in the cost of paying somebody to do security updates for all your dependencies which includes but is not limited to your OS and Go. Maybe a bunch of companies with similar needs can get together and collectively maintain a long-term stable branch of Go. Or maybe you just need to use a version of Go that comes with Ubuntu LTS and rely on Ubuntu or your OS of choice's maintenance team to do the security backports for you.
But the answer is not upstream (us) doing security maintenance for five years. We can definitely answer questions on the mailing list about backports with conflicts, to the extent we remember, but we're not in the business of maintaining old software.

I should apologize for having pushed this discussion into a somewhat off-topic direction yesterday by mentioning the option of "sticking with 1.8" (but with the restriction "not worth the risk").
Go's value is so much more than the compiler. Many of the awesome (standard) libs have grown and got new features with each version. Think of the "legacy-limited + current-full" hardware platform scenario I mentioned above, and imagine you couldn't use the same import "context" in your application, and no third-party libs relying on it, only because one of the platforms sticks with pre-1.7 ...
I do not want to keep 1.8 alive for years, as this would completely cut innovation for the non-legacy platforms (besides the fact that there is no direct profit from legacy platform support, which makes it hard to budget).
What's imho much more interesting is the question of an ARM "backend split", as this touches Go's no.1 rule of simplicity.
As I understood it, Go currently supports only one single ARM code generation target, with the option to select different modes of FPU support.
For me professionally developing code for ARM CPUs since >16 yrs and having seen their core capabilities grow and change so much over time, this seems to be overly simplistic.
I certainly admit that it's a necessary tradeoff if "ease of use" is your primary concern.
But you will regularly have to "cut the old pigtails" then, as development won't stop with ARMv8.
I think there are many markets where hardware half-life time is short enough for this approach, ours isn't.
I would thus strongly opt for a more flexible, perhaps feature-based code generation strategy without the need to decide between "target split" and "cut off" with each new, but incompatible architectural feature.
Would it be hard to make ARMv6k the default target, but keep code for ARMv5 around (in the compiler) for those who really need it, and at the same time become open for new optimizations on not-yet mainstream CPU variants?
P.S.: Since I first learned to know Go I am dreaming of using it for bare-metal/RTOS development on Cortex-M CPUs - how could that ever come true with the current "there is but one" paradigm?

Would it be hard to make ARMv6k the default target, but keep code for
ARMv5 around (in the compiler) for those who really need it, and at the
same time become open for new optimizations on not-yet mainstream CPU
variants?

This is sort of true and sort of not true.
Ben Shi has submitted a number of CLs that add support in the arm backend
for new ARMv6 and v7 instructions. However those instructions are only
better ways to expressing the same operation, so if the chip doesn't
support it, we don't generate the instructions.
The problem with ARMv5 is there is no support for atomic operations like
LDREX which significantly complicate papering over the lack of this
instruction in the backend.

P.S.: Since I first learned to know Go I am dreaming of using it for
bare-metal/RTOS development on Cortex-M CPUs - how could that ever come
true with the current "there is but one" paradigm?

Thumb2 support is an entirely different kettle of fish, it would probably
be a different backend target, perhaps linux/thumb2. Thats how it was done
on plan9
On Tue, Feb 14, 2017 at 8:24 PM, Thomas Kurz<EMAIL_ADDRESS>wrote:

I should apologize for having pushed this discussion into a somewhat
off-topic direction yesterday by mentioning the option of "sticking with
1.8" (but with the restriction "not worth the risk").
Go's value is so much more than the compiler. Many of the awesome
(standard) libs have grown and got new features with each version. Think of
the "legacy-limited + current-full" hardware platform scenario I mentioned
above, and imagine you couldn't use the same import "context" in your
application, and no third-party libs relying on it, only because one of the
platforms sticks with pre-1.7 ...
I do not want to keep 1.8 alive for years, as this would completely cut
innovation for the non-legacy platforms (besides the fact that there is no
direct profit from legacy platform support, which makes it hard to budget).
What's imho much more interesting is the question of an ARM "backend
split", as this touches Go's no.1 rule of simplicity.
As I understood it, Go currently supports only one single ARM code
generation target, with the option to select different modes of FPU support.
For me professionally developing code for ARM CPUs since >16 yrs and
having seen their core capabilities grow and change so much over time, this
seems to be overly simplistic.
I certainly admit that it's a necessary tradeoff if "ease of use" is your
primary concern.
But you will regularly have to "cut the old pigtails" then, as development
won't stop with ARMv8.
I think there are many markets where hardware half-life time is short
enough for this approach, ours isn't.
I would thus strongly opt for a more flexible, perhaps feature-based code
generation strategy without the need to decide between "target split" and
"cut off" with each new, but incompatible architectural feature.
Would it be hard to make ARMv6k the default target, but keep code for
ARMv5 around (in the compiler) for those who really need it, and at the
same time become open for new optimizations on not-yet mainstream CPU
variants?
P.S.: Since I first learned to know Go I am dreaming of using it for
bare-metal/RTOS development on Cortex-M CPUs - how could that ever come
true with the current "there is but one" paradigm?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-279652750, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA5_MFNRJCir9xTgaSSorwgrFL4A8ks5rcXLIgaJpZM4J7K4x
.

Thanks a lot for clarification, @davecheney !
Can you point me to a document about Go's current backend architecture to help me get better understanding?

I'm afraid it's "use the source, Luke"
On Tue, 14 Feb 2017, 21:33 Thomas Kurz<EMAIL_ADDRESS>wrote:

Thanks a lot for clarification, @davecheney
https://github.com/davecheney !
Can you point me to a document about Go's current backend architecture to
help me get better understanding?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-279670371, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA37Uu30L7X1zGCmgPk2ARgJuTWjHks5rcYMLgaJpZM4J7K4x
.

@bradfitz OK I see. Thanks for the answer.

Thumb2 support is an entirely different kettle of fish, it would probably
be a different backend target, perhaps linux/thumb2. Thats how it was done
on plan9

Thumb support in Go would definitely be a new target, but Plan 9 never had a thumb port. There are thumb compilers for Inferno though.

If you still use Go on ARMv5E systems, please help by listing the processor
model used.

ARM926EJ-S (TI AM1808).

Couple of questions:

If ARM v5/6 support is dropped will there still be a way to target ARM v7 with no FPU / VFP support?

It appears to be a rare case but there are some v7 processors without VFP support is my current understanding (which admittedly is limited).

Would this affect gccgo as well?

If ARM v5/6 support is dropped will there still be a way to target ARM v7 with no FPU / VFP support?

No. They would have to use the kernel provided soft fpu.

Would this affect gccgo as well?

No.

@davecheney Thanks for the follow up.
I'm not sure I follow regarding using kernel provided soft fpu.
Today when I build and target GOARM=7 it generates an executable with e.g. vmov.f32 instructions. Is there a way to force ARMv7 to use soft fpu today and not generate those instructions? I basically hit the same issue as #18483 except I have no workaround.
It seems from the comments in this thread that vfp support is directly tied to the GOARM env variable so I was trying to ascertain how or if soft fpu will be supported for ARMv7 if ARMv5/6 is dropped.

On Wed, 8 Mar 2017, 10:05 Aaron Todd<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney Thanks for the follow up.
I'm not sure I follow regarding using kernel provided soft fpu.
Today when I build and target GOARM=7 it generates an executable with
e.g. vmov.f32 instructions. Is there a way to force ARMv7 to use soft fpu
today and not generate those instructions? I basically hit the same issue
as #18483 https://github.com/golang/go/issues/18483 except I have no
workaround.

What SoC are you using?
It seems from the comments in this thread that vfp support is directly tied

to the GOARM env variable so I was trying to ascertain how or if soft fpu
will be supported for ARMv7 if ARMv5/6 is dropped.

Yes, soft to support will be dropped.
—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17082#issuecomment-284889908, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA261rulIZhJP5720ZscsJ7ZDBkglks5rjeKygaJpZM4J7K4x
.

Ok thank you for clearing that up for me.

What SoC are you using?

It's an ARM Cortex A9 but vfp is not supported (hi3535 I believe). I inquired today about it and the response was essentially "vfp is not supported, yes it's rare for ARMv7, and yes it is unfortunate"

I don't know that it's a sure thing we will expire ARMv5. We said we would in the Go 1.8 release notes, so we could do so in Go 1.9, but a number of people above have requested continuing support. We moved over to #19075 to figure out the general policy, and once that's settled (it looks mostly settled) we'll need to return here.

Based on the considerations listed at the end of #19075 (hardware is still available, users still want it, upkeep has minimal costs), we will keep GOARM=5 going for a while longer.
Therefore declining proposal.


Add project run configuration

Purpose
Brings project run configs into source control
Learning
This will break your current PHPStorm config without appropriate preparation.

Exit PHPStorm
Backup current run folder
mv .idea .idea-bak
Checkout master/branch
Start PHPStorm
Remove backup (optional)
rm -R .idea-bak

Checklist

[x] I have performed a self-review of my own code
[ ] I have added relevant logging with appropriate levels to my code
[ ] I have updated documentation (Confluence/GitHub wiki/tech debt doc) where relevant
[ ] I have added tests to prove my work
[ ] The product team have tested these changes

Coverage remained the same at 76.02% when pulling 5c7c232a52c03e63d810451ff6c52db32a6616ae on project-config into efc191dcb49948ef683333db4813310f704dbee2 on master.


Properties using CustomType are migrated as JSON columns

From the documentation:

To store dates without time information, we can use DateType. It does use date column type and maps it to the Date object.
@Property({ type: DateType, nullable: true })
born?: Date;

If I try to create a migration, the born field will be created as a JSON, and not as and date as the documentation suggests.
this.addSql('create table `user` (`id` varchar(255) not null, `born` json not null, ...

I've tried with the different custom types that come bundled with MikroORM, but all of them seem to be understood as a JSON when creating migrations.
To Reproduce
Steps to reproduce the behavior:

Create an entity and add the code above from the documentation
Run npx mikro-orm migration:create --initial
Open the Migration file, the field is set to be created as an json

Expected behavior
The property should be created as a date column.
Additional context
Happens using either postgresql or mysql drivers.
Versions

Dependency
Version

node
v12.19.1

typescript
^4.0.5

mikro-orm
^4.4.1

@mikro-orm/mysql
^4.4.1

Please provide full reproduction, this is tested and works fine in tests:
  @Property({ type: DateType, index: true, nullable: true })
  born?: Date;

create table \`author2\` (
  \`id\` int unsigned not null auto_increment primary key,
  \`created_at\` datetime(3) not null default current_timestamp(3),
  \`updated_at\` datetime(3) not null default current_timestamp(3),
  \`name\` varchar(255) not null, \`email\` varchar(255) not null,
  \`age\` int(11) null default null,
  \`terms_accepted\` tinyint(1) not null default false,
  \`optional\` tinyint(1) null,
  \`identities\` text null,
  \`born\` date null,
  \`born_time\` time null,
  \`favourite_book_uuid_pk\` varchar(36) null,
  \`favourite_author_id\` int(11) unsigned null
) default character set utf8mb4 engine = InnoDB;
alter

https://github.com/mikro-orm/mikro-orm/blob/master/tests/entities-sql/Author2.ts#L45
https://github.com/mikro-orm/mikro-orm/blob/master/tests/__snapshots__/SchemaGenerator.test.ts.snap#L51
Also, do you really want to use the DateType? It is rather a toy type, it does store dates (only dates, no time or TZ), mapping them to Date object.

Here's a minimal repo with the issue happening, it contains a start script in the package.json that creates a migration file where the column type is json. There's also added a custom type to test if the getColumnType method is ignored altogether.
https://github.com/mukaschultze/mikro-orm-issue-1385
It was tested both with ReflectMetadataProvider and TsMorphMetadataProvider, the two had the same result.
The package-lock only contains one entry of @mikro-orm/core, so I guess the versions are aligned.
I don't really need the DateType, but this seems to affect other custom types as well, and they are pretty handful.
I've also added the import 'reflect-metadata' at the top, didn't make much of a difference.

In that project you don't even have @mikro-orm/cli as a dependency. That makes me even more sure you have misaligned depedencies, the CLI should be installed locally.

That was it, thanks! I had<EMAIL_ADDRESS>installed globally.
Btw, I couldn't find anything in the documentation that says the CLI has to be installed locally, in fact, it has an "example" for global installs:
# or when installed globally
$ mikro-orm

Anyway, thanks for the help	you may close this issue if you want.

Mmmm I guess I should remove that note and state that the CLI should be installed always locally.
The issue here is that if you have one global installation, it will have its own @mikro-orm/core package. Then there will be another one in your local project dependencies. Now the problematic part is that if your entity uses custom type instance from the locally installed package, the global one will have another version of that type class - and using instanceof checks will fail.
Very same problem happens if you have misaligned versions, e.g<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(unless they both resolve to the same version).


Loading scenarios pikle in metradrive

Hi guys, When I tried to load scenarios using this scenarios pickle files : https://github.com/metadriverse/trafficgen/blob/main/trafficgen/dataset/README.md
using this version of metadrive at this commit : b58863f13354fb055663f09b21e110017ddc22ae
and using this script : https://github.com/metadriverse/trafficgen/blob/main/trafficgen/run_metadrive.py
I have this type of error in the screenshot, I cant really understand the source of this error. Please help me ! Thank you !

Hi, I fixed the issue with latest metadrive. Please pull TrafficGen and see if everything work. Please feel free to inform me the result and reopen the issue. Thanks!


1421 update logs for Unicode Nul character

Description
this fixes #1421
The logs were false in that not the whole row was drop, but instead if parsing failed with a Unicode Nul character the specific column it was intended for is recorded as nul.
This also effected a couple of other places so those were updated too.
[db-sync-node:Warning:75] [2024-01-31 11:02:29.12 UTC]  prepareTxMetadata: Column 'json' in table 'metadata' was recorded as null, due to a Unicode NUL character found when trying to parse the json.

This also fixes #1623 as outputting the full json made logs quite perplexing.
Checklist

[ ] Commit sequence broadly makes sense
[ ] Commits have useful messages
[ ] New tests are added if needed and existing tests are updated
[ ] Any changes are noted in the changelog
[ ] Code is formatted with fourmolu on version <IP_ADDRESS> (which can be run with scripts/fourmolize.sh)
[ ] Self-reviewed the diff

Migrations

[ ] The pr causes a breaking change of type a,b or c
[ ] If there is a breaking change, the pr includes a database migration and/or a fix process for old values, so that upgrade is possible
[ ] Resyncing and running the migrations provided will result in the same database semantically

If there is a breaking change, especially a big one, please add a justification here. Please elaborate
more what the migration achieves, what it cannot achieve or why a migration is not possible.

Column 'json' in table 'metadata' was recorded as null, due to a Unicode NUL character found when trying to parse the json.

This is definitely more clear, but I wonder if it's a little too verbose

This is definitely more clear, but I wonder if it's a little too verbose

how about
The 'json' column in 'metadata' became null due to a Unicode NUL character in the JSON parsing process.


support check groupId

Codecov Report
Base: 40.85% // Head: 40.76% // Decreases project coverage by -0.09% :warning:

Coverage data is based on head (1f7e92b) compared to base (4626a88).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #183      +/-   ##
==========================================
- Coverage   40.85%   40.76%   -0.10%
==========================================
  Files          33       33
  Lines        2303     2313      +10
==========================================
+ Hits          941      943       +2
- Misses       1243     1252       +9
+ Partials      119      118       -1

Impacted Files
Coverage Δ

pkg/kafsar/kafsar_impl.go
42.54% <0.00%> (+0.57%)
:arrow_up:

pkg/network/kafka.go
15.69% <ø> (+6.97%)
:arrow_up:

pkg/network/kafka_offset_fetch.go
0.00% <0.00%> (ø)

pkg/network/sasl.go
0.00% <0.00%> (ø)

pkg/test/test_kafsar_flow_impl.go
44.44% <0.00%> (-5.56%)
:arrow_down:

pkg/test/test_kafsar_impl.go
44.44% <0.00%> (-5.56%)
:arrow_down:

pkg/kafsar/group_coordinator_standalone.go
64.77% <0.00%> (-3.29%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add dead code detection

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.99%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1182      +/-   ##
==========================================
+ Coverage   94.96%   94.99%   +0.02%
==========================================
  Files         104      104
  Lines       12499    12559      +60
==========================================
+ Hits        11870    11930      +60
  Misses        480      480
  Partials      149      149

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add a cheminformatics and molecule rendering visualization to the advanced visualizations

RDkit.js is a JavaScript library for rendering molecule structures in the browser:
https://github.com/rdkit/rdkit-js
Graph analysts in the healthcare domain can benefit signifcantly from rendered molecular data represented in Neo4j.
We can implement rendering for this type visualization based on the examples provided here:
https://react.rdkitjs.com/
We can also take inspiration from the various examples that can be found on Github:
https://github.com/search?q=rdkit+MoleculeStructure&type=code
CC @stuartgreen4j @jarasch

+1000 this would be super useful! I am currently passing info in a URL header to an iframe node, but this would be a huge quality of life improvement!


On Rancher Server upgrade, new Rancher hosts won't start any containers successfully

Rancher Versions:
Server: v1.5.9
healthcheck: v0.2.3
ipsec: v0.0.5
network-services: v0.2.0
scheduler: v0.5.1
kubernetes (if applicable):
Docker Version:
1.12.6 - Database Hosts (Fine)
17.03.0-ce - Compute Hosts
OS and where are the hosts located? (cloud, bare metal, etc):
RancherOS v0.8.1 - DB
RancherOS v1.0.1 - Compute Hosts
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single Node Rancher, external DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:

Killed rancher/server:stable
Pulled latest rancher/server:stable
Started rancher/server:stable
All current hosts upgraded to agent version v1.2.2 due to rancher
All hosts then upgraded to Network Services v0.2.2
Destroyed old Compute Servers to upgrade underlying RancherOS to LTS (v1.0.1 from v0.9.1)
New Hosts get Timeout unable to get IP

Results:
The new version of Rancher automatically updated:

Agents across the cluster
Network Services

The Agent upgraded fine, but all Network Stacks were stuck in "Upgraded" state. As such, any new host that was added to the cluster would start creating the "System Services", but every container would fail due to Timeout unable to get IP. Turns out, due to being in the Upgraded state, the Rancher Network Stack (Metadata and Network-Manager) was not propagating to any new hosts added to the cluster.
Being that the Network Stack is a dependency for any container managed under a Rancher Host to work, Rancher should automatically either:

Finish the Upgrade
Only bring up the new version, on rollback, bring up the old version
Bring up the old version, then rollover to the new version (then be in the same state as other hosts)
Give the user a Toaster notification saying 'Confirm Infrastructure Stack Upgrades?'

Conversely, this issue will go away when the "Upgraded" step is removed in a later version of Rancher. (Was mentioned in the last Rancher monthly meetup)

The "Finish the Upgrade" step is going to be removed.  There is currently a big issue in that when in the "Upgraded" state we don't reconcile services, meaning nothing happens.  If services are left in "Upgraded" then it is effectively in a "Pause" or "Do nothing" state.  As such we are removing it.  I'm currently working on that (and a lot of other reliability issues around upgrades in general).

@MatthewHartstonge Did you upgrade from Rancher <= 1.4?  The network services only auto upgrades when going from one of those versions (1.2, 1.3, 1.4).  If you upgrade now from 1.5.x to 1.6 (just released today) we won't auto upgrade anything.

@ibuildthecloud upgraded from 1.5.3 -> 1.5.9 (was staging/UAT) so didn't matter, but will be an issue to remember/know of until 1.6 is :stable.

Closing as will be fixed in version 1.6.X+ of Rancher. 👌


Display duplicate blobs after uploading the same one blob with 'Use AzCopy ...' disabled

Storage Explorer Version: 1.5.0
Platform/OS Version: Windows 10/ Linux Ubuntu 16.04/ MacOS High Sierra
Architecture: ia32/x64
Build Number: 20180929.2
Commit: a985fab8
Regression From: Not a regression
Steps to Reproduce:

Enable 'Use AzCopy for Improved Blob Upload and Download' -> Upload one blob.
Disable 'Use AzCopy for Improved Blob Upload and Download' -> Upload the same one blob.
Select 'Replace' on 'Upload Conflict' dialog -> Apply.
Check the result after replacing successfully.

Expected Experience:
Succeed to replace and only one blob displays.
Actual Experience:
Display duplicate blobs without refreshing manually.

This is the same bug as #183 , except AzCopy is not setting a good content type. They are aware of this issue, so I'll close this as a duplicate of 183.


isGovernment attribute for checking whether user is IDIR or BCEID

follow-up for ZEVA-28
Changelog:

Added fixture for adding Government as an organization
Added isGovernment column for organizations
Added isGovernment property for User
Move token for authorization as a configuration
Updated navbar and other sections to read from the call to the user

Close this pr as the files are included in pr#24


Moq panics when trying to mock function which returns imported type

I have an interface in one of my packages with the structure
//go:generate moq -out mock_persistence_data_test.go . persistenceClient
type persistenceClient struct {
  EnsureSchema()
  GetUnfinishedSchedules() (*[]persistence_data.ScheduleRequest, error)
}

Recently, moq has suddenly started panicking whenever I try to run go generate, and I can't work out why. I have managed to work out that it only happens when there's a function in the mocked interface which returns a type imported from a different package, but I can't work out why it's a problem. The error messages in themselves are unhelpful - I get a go/format: expected ), got type error, followed by the moq usage string, followed by running "moq": exit status 1
It's starting to look like our only option is to refactor the entire program to not use moq any more, which is something I'm loathe to do...

Can you please share a repo or zip file with which I can reproduce the issue? I tried to do so but the mock was generated correctly without any problem.
-- testmock/issue123/persistence_client.go
package issue123

import "testmock/issue123/persistence_data"

//go:generate moq -out mock_persistence_data_test.go . persistenceClient
type persistenceClient interface {
  EnsureSchema()
  GetUnfinishedSchedules() (*[]persistence_data.ScheduleRequest, error)
}

-- testmock/issue123/persistence_data/schedule_req.go
package persistence_data

type ScheduleRequest int

-- testmock/issue123/mock_persistence_data_test.go
// Code generated by moq; DO NOT EDIT.
// github.com/matryer/moq

package issue123

import (
	"sync"
	"testmock/issue123/persistence_data"
)

var (
	lockpersistenceClientMockEnsureSchema           sync.RWMutex
	lockpersistenceClientMockGetUnfinishedSchedules sync.RWMutex
)

// Ensure, that persistenceClientMock does implement persistenceClient.
// If this is not the case, regenerate this file with moq.
var _ persistenceClient = &persistenceClientMock{}

// persistenceClientMock is a mock implementation of persistenceClient.
//
//     func TestSomethingThatUsespersistenceClient(t *testing.T) {
//
//         // make and configure a mocked persistenceClient
//         mockedpersistenceClient := &persistenceClientMock{
//             EnsureSchemaFunc: func()  {
// 	               panic("mock out the EnsureSchema method")
//             },
//             GetUnfinishedSchedulesFunc: func() (*[]persistence_data.ScheduleRequest, error) {
// 	               panic("mock out the GetUnfinishedSchedules method")
//             },
//         }
//
//         // use mockedpersistenceClient in code that requires persistenceClient
//         // and then make assertions.
//
//     }
type persistenceClientMock struct {
	// EnsureSchemaFunc mocks the EnsureSchema method.
	EnsureSchemaFunc func()

	// GetUnfinishedSchedulesFunc mocks the GetUnfinishedSchedules method.
	GetUnfinishedSchedulesFunc func() (*[]persistence_data.ScheduleRequest, error)

	// calls tracks calls to the methods.
	calls struct {
		// EnsureSchema holds details about calls to the EnsureSchema method.
		EnsureSchema []struct {
		}
		// GetUnfinishedSchedules holds details about calls to the GetUnfinishedSchedules method.
		GetUnfinishedSchedules []struct {
		}
	}
}

// EnsureSchema calls EnsureSchemaFunc.
func (mock *persistenceClientMock) EnsureSchema() {
	if mock.EnsureSchemaFunc == nil {
		panic("persistenceClientMock.EnsureSchemaFunc: method is nil but persistenceClient.EnsureSchema was just called")
	}
	callInfo := struct {
	}{}
	lockpersistenceClientMockEnsureSchema.Lock()
	mock.calls.EnsureSchema = append(mock.calls.EnsureSchema, callInfo)
	lockpersistenceClientMockEnsureSchema.Unlock()
	mock.EnsureSchemaFunc()
}

// EnsureSchemaCalls gets all the calls that were made to EnsureSchema.
// Check the length with:
//     len(mockedpersistenceClient.EnsureSchemaCalls())
func (mock *persistenceClientMock) EnsureSchemaCalls() []struct {
} {
	var calls []struct {
	}
	lockpersistenceClientMockEnsureSchema.RLock()
	calls = mock.calls.EnsureSchema
	lockpersistenceClientMockEnsureSchema.RUnlock()
	return calls
}

// GetUnfinishedSchedules calls GetUnfinishedSchedulesFunc.
func (mock *persistenceClientMock) GetUnfinishedSchedules() (*[]persistence_data.ScheduleRequest, error) {
	if mock.GetUnfinishedSchedulesFunc == nil {
		panic("persistenceClientMock.GetUnfinishedSchedulesFunc: method is nil but persistenceClient.GetUnfinishedSchedules was just called")
	}
	callInfo := struct {
	}{}
	lockpersistenceClientMockGetUnfinishedSchedules.Lock()
	mock.calls.GetUnfinishedSchedules = append(mock.calls.GetUnfinishedSchedules, callInfo)
	lockpersistenceClientMockGetUnfinishedSchedules.Unlock()
	return mock.GetUnfinishedSchedulesFunc()
}

// GetUnfinishedSchedulesCalls gets all the calls that were made to GetUnfinishedSchedules.
// Check the length with:
//     len(mockedpersistenceClient.GetUnfinishedSchedulesCalls())
func (mock *persistenceClientMock) GetUnfinishedSchedulesCalls() []struct {
} {
	var calls []struct {
	}
	lockpersistenceClientMockGetUnfinishedSchedules.RLock()
	calls = mock.calls.GetUnfinishedSchedules
	lockpersistenceClientMockGetUnfinishedSchedules.RUnlock()
	return calls
}

Ok, it looks like I've managed to fix the issue, although I don't know why the problem was happening or why what I did fixed it - I had a shell script running whenever I made a merge request to my project, which ran go get moq, generated the mocks and ran the tests.
For some reason this started failing at some point (although I didn't make any changes relating to that part of the codebase), and the solution was to remove the go get github.com/matryer/moq call from the shell script, as the computer running it already had moq installed. My best guess is that maybe it was the fact it was being run in the project source directory itself might have been a problem? That or the fact that my project uses go modules and I don't think moq does... Either way, this problem seems to be resolved (if unsatifactorily) for my use case.


Notify peers when they're banned

There's code in Gossip_net to read from the ban pipe. When a ban occurs, there's a call to a new Rpc, Ban_notify. The ban pipe now passes the banned-until time, as well as the IP address of the banned peer.
Upon notification, the banned peer uses Logger.warn to print out the banning peer and the ban expiration time.
Tested by temporarily making the notification occur on every connection, running the five-even-snarkless multiproposer test, and verifying the log message is printed.
The notification is eager, in the sense that it's sent when we get an entry on the ban pipe. Initially, the implementation sent the message when a banned peer tried to connect.
Because the trust system bans by IP addresses, while the network can know of multiple peers at an address, peers may receive ban notifications that have nothing to do with their own actions.
Closes #3013.

Note that if peers from an already-banned IP address try to connect, they won't get notification, under this setup. If we notified upon connection, rather than when banned, and kept track of already-notified peers to prevent multiple notifications, we'd have the same issue.

the idea was that a peer that found out it was banned wouldn't try to connect to the banner until after the ban expired. It's fine with me to make an issue and defer that to future work.

I can think of how to implement that. Yes, please add an issue.

@enolan I opened https://github.com/CodaProtocol/coda/issues/3084 and assigned myself.


Correct some textual errors

Hi!
Thanks for maintaining the site. Please apply this pull-req with some corrections for spelling/etc. errors.

Thanks.

On Fri, 10 Mar 2017 01:55:05 -0800
Edlich<EMAIL_ADDRESS>wrote:

Thanks.

You're welcome and thanks for merging.
--
Shlomi Fish       http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html
Can I SCO now? Sue who you wanna sue, it doesn't matter anyhoo, it's time to
litigate.
— http://www.shlomifish.org/humour/bits/Can-I-SCO-Now/
Please reply to list if it's a mailing list post - http://shlom.in/reply .


Does the agent support auto jump?

If the character wants to jump from one isolated area to another, can the jump route be generated automatically without adding jump link manually?

With "jump", you mean an off-mesh connection?
If you don't add those connections, how would Recast/Detour know which jumps are valid and which aren't?

Oh, I'm sorry. Maybe I didn't make it clear. I mean whether the function of automatically generating off-mesh connections is supported, just like in unity.


Sometimes get "Cannot add or update a child row" due to foreign key reference missing

Hi i'm getting this error from time to time when my nestjs project is reloading due to changes in the code. I run it in watch mode locally so it reloads the seeder everytime so I have data to debug.
Here is the error, made it more generic, but it basically says that the Foreign Key ID in the table I want to reference does not exist yet:
[Seeder] [ERROR...] Cannot add or update a child row: a foreign key constraint fails (database.Table1, CONSTRAINT Constraint_ibfk_1 FOREIGN KEY (ForeignKeyId) REFERENCES Table2 (id) ON DELETE NO ACTION ON UPDATE CASCADE)
E.g.:
Loading cat row into db before the row for breedId 2 has been loaded results in the error above.
First loaded
Cat: {
id = 1;
breedId = 2;
}
Loaded second
Breed: {
id = 2;
name = persian;
}

Hello, there!
Did you try deleting the database ?

Sequelize creates a table when it's not created, otherwise it doesn't create anything, nor does it update any columns !

Tell me, did it work ?

También puede ser el orden, de la ejecución.
por ejemplo, cuando sequelize retorna un error, al crear un nuevo objeto para su modelo, ahi el id se incrementará, por lo tanto no coincidiran las asociaciones agregadas.
Mire la unica solucion seria, agregar un id desde la data de un seed,
Para Breed
const data = [
breedId: 1,
]

Si no te funciono, puedes escribir con mas detalles aqui , para poder ayudarte !

It can also be the order, of the execution.
For example, when sequelize returns an error, when creating a new object for your model, there the id will increase, therefore the added associations will not match.
First you will have to execute the tables in their proper order, for example, if you create a breed and cat table, and associate it, then you will have to execute the breed table first and then cat, since the cat table depends on the breed table.
With nestjs it's easy to sort, the modules.
Module({
   imports: [
      // First
      BreedModule,
      // Second
      CatModule,
   ],
});
class AppModule {}

For the 'Breed' seed
const data = [
   {
      // Here don't forget to add the id
      id: 1,
      name: 'persian',
   },
];

For the 'Cat' seed
const data = [
   {
      // You'll also have to add an id, to save us some trouble
      id: 1,
      breedId: 1,
   },
];

I hope this helps you!

That didn't fix it for me. Can you try to recreate it with a local MySQL db?

Oh i see you made a new release, will implement that first and let you know if it solved the issue.
I'm excited to tryout your new features! looks great, especially the hashing of passwords in the everyone() function was something i was struggling with to implement in a clean way with the v1.0.7 release.
I'll keep you updated

Hmmm now it seems to have all the same issues, but also it seeds data into the wrong table,
I think due to same column names, i have a name column in table A & in table B but data for table B.name gets seeded into table A.name ...that's a bug i'd say, I followed the readme very closely and i'm getting general foreign key issues as well

Junction table issue
I'd also like to point out i'm using a junction table for my CatBreed many-to-many relation. I'm having  some issues with this is well. The db cant find the FK relation id's of the Cat & Breed models (example: catId, breedId).
This worked perfectly in v1.0.7 of "nestjs-sequelize-seeder"
At the moment those error logs have stopped appearing after playing around with the settings, not sure if it's still there or not. Just going to mention it anyway.
Here is my junction table seeder:
@Seeder({
    unique: [],
    model: CatBreed
})
export class SeedCatBreeds implements OnSeederInit {
    run() {
        return [
            {id: 1, catId: 1, breedId: 1},
            {id: 2, catId: 1, breedId: 4},
            {id: 3, catId: 2, breedId: 2},
            {id: 4, catId: 2, breedId: 3},
        ] as CatBreed[];
    }
}

my junction table model:
@Table
export class CatBreed extends Model<CatBreed> {
    @PrimaryKey
    @AutoIncrement
    @Column
    id: number;

    @ForeignKey(() => Breed)
    @Column
    breedId: number;
    @BelongsTo(() => Breed)
    breed: Breed;

    @ForeignKey(() => Cat)
    @Column
    catId: number;
    @BelongsTo(() => Cat)
    cat: Cat;
}

this is another error, which is a weird one, since CatBreed does not have a name column... why would it look for that
@Seeder({
    model: Cat,
    unique: ['name'], // -> this gives an error:
                        // Error: [SeederService] Unknown column 'CatBreed.name' in 'where clause'
})
export class SeedCats implements OnSeederInit {
    run() {
        return [
            {
                id: 1,
                name: 'Mr Mistofeles',
            },
        ]
    }
}

getting validationErrors often as well :
Unhandled rejection SequelizeUniqueConstraintError: Validation error
    at Query.formatError (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/sequelize/lib/dialects/mysql/query.js:223:16)
    at Execute.handler [as onResult] (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/sequelize/lib/dialects/mysql/query.js:51:23)
    at Execute.execute (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/mysql2/lib/commands/command.js:30:14)
    at Connection.handlePacket (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/mysql2/lib/connection.js:417:32)
    at PacketParser.onPacket (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/mysql2/lib/connection.js:75:12)
    at PacketParser.executeStart (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/mysql2/lib/packet_parser.js:75:16)
    at Socket.<anonymous> (/mnt/b020cfba-0b36-4fcc-b0d7-3edea52ca1b3/courses/nestjs-course/node_modules/mysql2/lib/connection.js:82:25)
    at Socket.emit (events.js:311:20)
    at addChunk (_stream_readable.js:294:12)
    at readableAddChunk (_stream_readable.js:275:11)
    at Socket.Readable.push (_stream_readable.js:209:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:186:23)

also still getting this error:
Unhandled rejection SequelizeForeignKeyConstraintError: Cannot add or update a child row: a foreign key constraint fails (`animals`.`CatBreeds`, CONSTRAINT `CatBreeds_ibfk_1` FOREIGN KEY (`catId`) REFERENCES `Cats` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)

I think this erros is caused due to the "cat" that needs to be referenced isn't loaded yet.
I've kept an eye in terms of order of loading modules & seeders where the ones with FK's get loaded last.
So that's not the issue I think.
I've also deleted the database as well.
These are my settings for sequilize and the seeder module
SequelizeModule.forRootAsync({
        useFactory: () => {
            return {
                ...
                autoLoadModels: true,
                synchronize: true,
                sync: {
                    force: true,
                },
                ...
            };
        },
    }),

SeederModule.forRoot({
    isGlobal: true,
    logging: true,
    connection: 'animals',
}),

package.json
"nestjs-sequelize-seeder": "~1.0.9",
"sequelize": "^5.21.6",
"sequelize-cli": "^5.5.1",
"sequelize-typescript": "^1.1.0",
"@nestjs/sequelize": "^0.1.0",
"@types/sequelize": "^4.28.8",
"mysql2": "^2.1.0",


feat(paths): Fix some paths

Fixes:

Update paths of some generated files and generated configurations

:tada: This PR is included in version 1.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update README.md

Summary

Changes

Closes:
Task list

[x] For workflow changes, I have verified the Actions workflows function as expected.
[x] For content changes, I have reviewed the style guide.

Update the game over message


Items Not Showing Up In Logbook

Item previews don't show up in logbook. Happens for all items in the mod.

Most likely Unity version issue, will be fixed in next update. I'll leave this ticket open until I release the fix.

SOTS seems to have changed the way models are displayed. All vanilla items now have a black background instead of the purple floor, similar to how enemy models are done. I know ClassicItemsReturns has fixed this issue for their mod though. It would also be nice to at least get some sort of description, at least a data scraper saying no data available would look nice.


Debugging does not work with Live Extension enabled

Upstream Live Share Extension
https://github.com/MicrosoftDocs/live-share/issues/575
https://github.com/MicrosoftDocs/live-share/issues/249
/c @brettcannon @qubitron

This is impacting the survey for people with Live Share extension installed.
Hence will have to be resolved.

Is this still the case? Can we close this?

Test debugging with live share installed.

Confirmed that this is working on VS Code 1.31.1, Python extension 2019.2.5558.


Trim & Untrim results in different hashes

I was looking for a tool to compress/trim 3DS games (Encrypted and decrypted) and also to decompress/untrim 3DS games to get the original roms back. The reason is to verify roms with no-intro and to archive them in a compressed form. If required the roms should be decompressed/untrimmed to verify the no-intro checksum.
I tried now several roms with the trim/unteim feature. However it seems that roms larger than 4GB cannot be untrimmed. The hashes do not equal the original hashes from no-intro.
Steps to reproduce:

Get a encrypted 3DS rom for Bravely Dedault
Check the hash with the no-intro dat in romcenter
Trim the 3DS rom with 3DSTool.
check and verify that the size and hash of the rom is changed (smaller size)
untrim the rom with 3DSTool
-check the size and hash

You will recognize that after the unteimming process the size is correct, however the hash and file structure is wrong (verified with rom center)

名称: Bravely Default - Flying Fairy (JPN).3ds
大小:<PHONE_NUMBER> 字节 (2048 MiB)
CRC32: 3E5C01E4

3dstool -rf "Bravely Default - Flying Fairy (JPN).3ds"

名称: Bravely Default - Flying Fairy (JPN).3ds
大小:<PHONE_NUMBER> 字节 (1874 MiB)
CRC32: 6314820A

3dstool -pf "Bravely Default - Flying Fairy (JPN).3ds"

名称: Bravely Default - Flying Fairy (JPN).3ds
大小:<PHONE_NUMBER> 字节 (2048 MiB)
CRC32: 3E5C01E4

名称: Bravely Default (EUR).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: 83FB5F9C

3dstool -rf "Bravely Default (EUR).3ds"

名称: Bravely Default (EUR).3ds
大小:<PHONE_NUMBER> 字节 (3346 MiB)
CRC32: B59EA913

3dstool -pf "Bravely Default (EUR).3ds"

名称: Bravely Default (EUR).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: 83FB5F9C

名称: Bravely Default (USA).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: 0F123106

3dstool -rf "Bravely Default (USA).3ds"

名称: Bravely Default (USA).3ds
大小:<PHONE_NUMBER> 字节 (3342 MiB)
CRC32: 8EF749A9

3dstool -pf "Bravely Default (USA).3ds"

名称: Bravely Default (USA).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: 0F123106

名称: Bravely Default - For the Sequel (JPN).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: FB356EE6

3dstool -rf "Bravely Default - For the Sequel (JPN).3ds"

名称: Bravely Default - For the Sequel (JPN).3ds
大小:<PHONE_NUMBER> 字节 (3336 MiB)
CRC32: 6DC5F3F7

3dstool -pf "Bravely Default - For the Sequel (JPN).3ds"

名称: Bravely Default - For the Sequel (JPN).3ds
大小:<PHONE_NUMBER> 字节 (4096 MiB)
CRC32: FB356EE6

Thanks a lot!
It is working!
Used the wrong command.


[BUG] The header of Alerting monitor details flyout is not aligned with the page tabs height

What is the bug?
The header of the monitor details flyout has the same type of underline as the tabs on the page. The two lines almost meet at the edge of the flyout, but the difference in the positions of the lines is too small to look intentional, which brings an appearance of a bug.
How can one reproduce the bug?
Steps to reproduce the behavior:

Go to Alerting
Click on any entry in the Alerts by trigger table (assuming that the table is populated)
See the flyout with monitor details

What is the expected behavior?
The lines under the page tabs and the flyout title should either be on the same level or farer apart for the page to look organized in a more structured way.
What is your host/environment?

OS: macOS
Version 12.4
Plugins Alerting
Browser Chrome, Firefox, Safari

Do you have any screenshots?

Good catch. If the lines can't be the same, I'll make the flyout header a little bigger so the difference looks more intentional.

No longer relevant as we moved to using overlay type of flyouts.


Support for Input Multiplexers

Support for Multiplexer devices on Mobiflight Connector
Matches firmware PR 135 - firmware issue  119
Devices: MuxDriver and DigInMux
For every detail see firmware PR 135 as well as file Mobiflight_Multiplexer_info.pdf

THIS commit on official branch will require some modifications to more files in this PR. I have  to look for what changed (and why) and update accordingly.

Build fails with an error on MobiFlightUnitTests.csproj, which makes no sense to me (and shouldn't have neen affected anyway):
D:\a\MobiFlight-Connector\MobiFlight-Connector\MobiFlightUnitTests\MobiFlightUnitTests.csproj(369,5): error MSB4025: The project file could not be loaded. The 'Content' start tag on line 192 position 6 does not match the end tag of 'ItemGroup'. Line 369, position 5.

Hello everyone,
I'm a user come from Simvim and I made a MCP panel a few time ago.
Now, I would like to use Mobiflight whitout all rebuild from 0!!
So, I have read that now multplexer are supported.
I have create a new config in the app and I start to attribute my differents input.
But, I am quicky stopped because I can't to attribute all my switches, I explain:
My MCP panel use:

2 inputs multiplexers for all the switches (KD-22) and toggles
1 input multiplexer for all the encoders
1 output multiplexer for all the clock pin to the max7219 7 segment modules

All the led are connected on 2 cascaded shift register.
So, in Mobiflight:

I created my first input multiplexer (switch and toggle part 1), no problem -> OK
I created my second input multiplexer (switch and toggle part 2) -> OK
I would like to create a third input multiplexer for my encoders -> PB: Mobiflight can't to create more 2 multiplexers
I would like to create the output multiplexer -> impossible to choose in the option, not disponible in the drop down list.

So, could someone using such a configuration help me?
Can you tell me if in a future release the usable number of multiplexers will be increased?
Can you tell me if a multiplexer can be used as an output (for my 7 segments for example)
Thanks a lot for all your job,
Olivier

Hi Olivier,
first of all welcome to MobiFlight!
That's correct, multiplexers are supported, but with some limitations for now.
I'll try to briefly reply to your questions:

Right now, only 2 MPXs are supported (for digital inputs only), mainly to initially weed out possible issues in new code.
There is indeed space for expansion (and their number will probably be increased soon), but that's currently the limit. (I could help you to overcome this limit even now, but there's also the next issue...)

MPXs could technically be used for outputs (more precisely: to multiplex output devices) in MF, to a level that's practically 100% compatible with SimVim/RSC; it's just not implemented right now.
But I would suggest everyone interested to voice their request for such features (the Discord channel is a perfect place for that), in order to show that there's enough interest to posssibly trigger the decision to include them.

Please join the Discord channel for further questions and also to keep informed (and involved) in the new developments!
Regards
GiorgioCC

Thanks for your response!!
It's a good news for me!!
I accept to give the help as possible but my knowledge is very modest. On
the other hand, I can test without worry if necessary.
I have already to try to connect me on the discord but I don't have find
where I can speak about multiplexers.
can you say me?
thanks a lot
Olivier
Le jeu. 1 sept. 2022 à 13:59, GioCC @.***> a écrit :

Hi Olivier,
first of all welcome to MobiFlight!
That's correct, multiplexers are supported, but with some limitations for
now.
I'll try to briefly reply to your questions:

Right now, only 2 MPXs are supported (for digital inputs only), mainly
to initially weed out possible issues in new code.
There is indeed space for expansion (and their number will probably be
increased soon), but that's currently the limit. (I could help you to
overcome this limit even now, but there's also the next issue...)
MPXs could technically be used for outputs (more precisely: to
multiplex output devices) in MF, to a level that's practically 100%
compatible with SimVim/RSC; it's just not implemented right now.
But I would suggest everyone interested to voice their request for
such features (the Discord channel is a perfect place for that), in
order to show that there's enough interest to posssibly trigger the
decision to include them.
Please join the Discord channel for further questions and also to keep
informed (and involved) in the new developments!
Regards
GiorgioCC
—
Reply to this email directly, view it on GitHub
https://github.com/MobiFlight/MobiFlight-Connector/pull/651#issuecomment-1234179421,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHDARXBLVPL6KFS56JHJFQTV4CLAZANCNFSM5LO6Q6YQ
.
You are receiving this because you commented.Message ID:
@.***>