Hello can not be resolved to a type

@{
  class Hello {
    String hello="Hello";
  }
  Hello hello=new Hello();
}
@def sayHello(Hello hello) {
  @hello.hello
}
@hello.hello
@sayHello()

this is a very important feature

Your template needs a little bit update. Checkout http://fiddle.rythmengine.org/#/editor/18af81d8a5d1412da6945760ae92a103

It would be very helpful to simplify the syntax and remove the unneccessary @def.
Adding the @def makes the code hard to read, cut&paste is more difficult and there is another thing that needs explanation. If you simply parse the class as if it had @def we are all set.

@WolfgangFahl there are two things actually:

The @{ } marks an inline code block in the render method, meaning everything defined inside it belongs to the method runtime scope including the classes defined inside it. While @def class <ClassName> {} clearly define something that is outside of the render method scope, which means the class defined with the leading directive @def class is a static inner class of the template. Semantically it clearly differentiate the two things in terms of scope.

Your code confuse the operating scopes by trying to refer the inner class defined in the render method from another class method, in your example sayHello which is defined again by the @def directive. That's why it complain that Hello class is not found.

Aesthetically I wouldn't accept the solution that take class definition out of the @{} block and treat it as a static inner class of the template class. Sorry about that.

an common ground might be
@dev package A {
class A {
}
class B {
}
}
or
@dev java {
class something {
}
or
class another {
}
}
@dev code {
class C1 {
}
class C2 {
}
}
Currently for each class the @def has to be removed when debugging the content in a Java IDE. Also it's not possible to share the code between a JAVA IDE and Rythm. This is especially bad for the testability of the code. I'd rather test the code in a jenkins/maven/Eclipse environment and than use it as is within ryhthm then have to debug the code right in the Rythm environment. So it's not only about aesthetics. Not touching the Java code at all and being as Java compatible as possible are very important design goals from my point of view.

I see where you come from now. I will try to work out something for you this weekend

This is very good news indeed. I am looking forward to the results.

My apologize I missed the work last week coz the heavy work load from the company. Will catch up this week and keep you updated

See #271: Allow template author to add arbitrary code at class level

@WolfgangFahl can we close this issue now?


unsigned plugin V2.0.0

I am using Grafana 7.2.I installed the plugin manually and allowed unsigned plugins but l can't find the plugin in ui.please suggest Also plugin.json has version mentioned as 1.3 and Grafana dependency as 3.X.The plugins.tar download link has a typo with capital V in the doc linuxocii.md. May I know when this plugin will be signed and available as part of Grafana cli install.

Closing this issue as the new plugin is signed  and available in Grafana Labs.Thanks Athul .


Update libraries Android (2.5.0-beta.1) and iOS (2.3.0.beta-2)

Hello @tompi.
Finally screen sharing has arrived on iOS, as soon as the nuget version is available I will implement it for iOS.
https://github.com/Azure/Communication/releases

@andersonvieiragomeslopes updated nugets now. Let me know if you are missing something.
P.S. checked on the binding generated class parser file for android, so its easier to see which new methods I should add in the helper lib

Thanks @tompi.
https://github.com/Azure/azure-sdk/issues/4373

System audio sharing is also available, I will analyze and send you the necessary methods to add to the communication helper.

@andersonvieiragomeslopes as long as its not a Future, it should be available in the regular lib.
Its only the futures that are not caught by the binding lib.

Hi @tompi.

Maybe, this audio sharing api has been renamed, I didn't find it here and it seems that they put it inside this element (Call) as mentioned in this little code in the ticket above.

Hi @tompi
This ACSRoomCallLocator  It doesn't inherit from communication I think we have a problem with rooms support without this inheritance.
Please check it here.


Add governance guardrails tests for update pparams

This PR proposes tests for governance guardrails. This is based on the Plutus Governance guardrails script and default constitution. At first, the script is enacted and then checked for unconstitutional values/out-of-range values for all protocol parameters defined in the constitution along with a check to ensure that valid values are accepted as a protocol parameter governance action.
The parameters and their values are checked based on Plutus cardano-constitution.
commit db119872c0dfc8537a39d38cea8ef0b20c59ecb5
The default constitution file
https://github.com/IntersectMBO/plutus/blob/db119872c0dfc8537a39d38cea8ef0b20c59ecb5/cardano-constitution/data/defaultConstitution.json
The user stories are derived from this PR.
https://github.com/IntersectMBO/cardano-test-plans/pull/52
This PR is ready for review and waiting for user stories to be merged.

Thanks for the PR. So far I took only brief look and have several comments.
There can be improvements made to enable parallel run of the tests (they don't change the environment, apart from the setup, so I believe they can run in parallel) and collateral handling.
If you don't mind, I'll do the changes, it will be faster for me than writing detailed comments.

Thank you for the review comments and feedback.
I have addressed some of the comments.
We'd welcome the changes you'd like to make to the PR.
It'd be great if you could push the changes directly on the PR, get it merged if possible, or merge PR and then make the necessary changes to run them in parallel.
Or I can address those changes If there are some examples of tests currently running in parallel and how the setup is being done.

Looks like I cannot push to your PR. Can you give me access?

Looks like I cannot push to your PR. Can you give me access?

I just sent you an invite. It should give access now.


fix code formatting

Summary
fix formatting
Documentation checklist

[x] The documentation style guide has been adhered to.

@cloudflare/workers-docs @cloudflare/pcx-technical-writing can this be merged?

Hi @vicb
Actually, we're now using prettier on file save and we're using tabs to indent code blocks (also done by prettier). I'll give it one last pass locally to update the file, which will fix the indentation as you intended.

Hey @pedrosousa,
Thanks for your help.
I have a few questions for you:

Actually, we're now using prettier on file save

Using prettier is great - there are a lot of inconsistencies in the docs.
Why don't we format all the docs with that instead of doing it only on file save?
It would require to update the format script to include md and mdx files.
We would also probably need to add a few ignored folders.
I don't see any blockers on doing that and we would have a consistent formatting.
If the whole docs are formatted some PR might get merge conflicts but it would be easy to format them to remove the conflicts. I can help with that if needed.
Let me know what you think, is this has been discussed already or if I need to create a feature request.
The second question is to understand how PRs are merged in this repo. This PR is now approved, when will it get merged?
I have another PR that is waiting to be merged. No rush, I only want to understand the workflow here.
Thanks.

The use of prettier is definitely not consistent. We're checking internally whether our config is the best one (prettier can be a bit finicky with MD/MDX + tabs) and how we would approach a more global update.
I'll merge the PR now that the checks have finished.
Usually the assigned tech writer handles the review and the merge, but this may take a few days. Other internal folks with write access can also approve and merge PRs (usually when they're smaller or urgent).

Thanks @pedrosousa!

We're checking internally whether our config is the best one (prettier can be a bit finicky with MD/MDX + tabs) and how we would approach a more global update.

Let me know if there is anything I can help with here. Inconsistencies are bothering me so I would love to help unblock a global update.


Not working and causing conflict with new lib

HTTPoison is old (1.3.1 is out)
Plug is old (1.7 is out)
Cowboy is old (2.5 is out)
makes it really hard to use it as it starts to create a lot of conflich with existing newer deps

fixed with https://github.com/epinault/wobserver


ARM template generator

Have you released the ARM template generator yet ?  Or the "second ARM template generator" ?

I can't generate a template for APIM in Azure, I get:
Export template operation completed with errors. Some resources were not exported. Please see details for more information. (Code: ExportTemplateCompletedWithErrors)
The schema of resource type 'Microsoft.OperationalInsights/workspaces' is not available. Resources of this type will not be exported to the template. (Code: ResourceTypeSchemaNotFound, Target: Microsoft.OperationalInsights/workspaces)
Could not get resources of the type 'Microsoft.Web/sites/extensions'. Resources of this type will not be exported. (Code: ExportTemplateProviderError, Target: Microsoft.Web/sites/extensions)
Could not get resources of the type 'Microsoft.Web/sites/deployments'. Resources of this type will not be exported. (Code: ExportTemplateProviderError, Target: Microsoft.Web/sites/deployments)
Could not get resources of the type 'Microsoft.Web/sites/premieraddons'. Resources of this type will not be exported. (Code: ExportTemplateProviderError, Target: Microsoft.Web/sites/premieraddons)
Could not get resources of the type 'Microsoft.Web/sites/sourcecontrols'. Resources of this type will not be exported. (Code: ExportTemplateProviderError, Target: Microsoft.Web/sites/sourcecontrols)

any updates?

Is this marketing article or what? Customers need a generator.

http://mlogdberg.com/apimanagement/arm-template-creator  Best I've found so far...

Therefore, we will create and open source an ARM template generator to help you generate API templates based on Open API (aka., Swagger) files and policy files.

we will also provide a second ARM template generator to help you generate API templates by extracting configurations from an existing APIM instance. Likewise, this generator will also be open sourced.

@vladvino any updates please?

Yes @vladvino , what about your two, open source "ARM template generators"?

Still planned, but unfortunately we were not able to get to it yet. In the meantime to mitigate the need for generators you can reference OpenAPI and policy files directly from the templates.

Can you please give an example on how to do that?
On Fri, Nov 2, 2018 at 1:32 PM Vlad Vinogradsky<EMAIL_ADDRESS>wrote:

Still planned, but unfortunately we were not able to get to it yet. In the
meantime to mitigate the need for generators you can reference OpenAPI and
policy files directly from the templates.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-api-management-devops-example/issues/20#issuecomment-435449953,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AECCby_bbdj6lLpCo9E59Ek882zBY99Gks5urI-pgaJpZM4U2wwF
.

Closing as the creation and extraction generator tools are in progress and are documented on the repo


Add support to include initial RecordsWrite to be returned in RecordsRead and RecordsQuery

This is done by #637.


Support targeting multiple entities

Some events intrinsically needs to targets multiple entities.
For example collision events will need to be able to report to multiple entities. You can currently simulate this by cloning the event (which can contain lots of data like a vector of manifolds) and sending them to each entity.
I think the ability to natively target multiple entities would help a lot for this kind of use-case.

You would need to clone the event regardless. Events need to traverse the hierarchy and can be mutated. If you target two entities, you need two events.


Add coveralls and travis badges to readme

Preview here: https://github.com/uber-go/uberfx/blob/add-badges/README.md

Changes Unknown when pulling 8833cdc759bc781b113e7a3edd6170f6cb8b9f58 on add-badges into ** on master**.

Changes Unknown when pulling 5cbf681fe12bca284d6948d080ad9d796f3784bf on add-badges into ** on master**.

Need to figure out how to get coveralls to ignore the examples directory, which is currently tanking our coverage. Can do in a separate PR though.
@uber-go/service-framework

Changes Unknown when pulling dba0d39bf6282c3cd942594c6fe12094c9cb0a5f on add-badges into ** on master**.

Changes Unknown when pulling a7c6dc85485a4a1918ee7de592a6eec1c3c122a4 on add-badges into ** on master**.

Changes Unknown when pulling 42b08213f25db55a1082b62ecd4f77f112d0fc85 on add-badges into ** on master**.


Suggestion: Run ktlint analysis on demand

When opening a file, the plugin immediately checks the file. Also, in some situations, I can see that, while changing the file, the checks are stopped and I need to close and reopen the file to force the checks to run again (sometimes this even fails).
As a user, I would like to have:

Have an option to force the ktlint checks on the file. For example, an action with the name "Run ktlint checks on file" will force the checks on the current file. It does not format, it will just check and if any issue found, show them as warnings/error/none accordingly to the setting.
Have a checkbox in settings (just like "Enable ktlint") with "Only perform checks on demand". When that setting is enabled, opening a file does not automatically trigger the ktlint checks. If we want to check we will make use of point 1 above.

P.S. - You added "Format With ktlint" to the refactor menu but it's missing when we use the shortcut for "Refactor this".

Interesting! I'll dig in and see how feasible this is with the available Annotations API.
So far, this plugin doesn't manage anything to do with triggering annotations checks, but there might be a way to temporarily enable a check 🤔
One thing I've been looking into is adding support for is lint rules as Inspections which would allow on-demand analysis. Would that be a decent solution for your use case?

One thing I've been looking into is adding support for is lint rules as Inspections which would allow on-demand analysis. Would that be a decent solution for your use case?

Sorry. Don't know how that works

In upcoming release of the plugin, the behavior of the plug will be even more standardised. Like Ktlint, the plugin should help the developers to become more productive. Manual fixing of errors is a waste of time (given that you have configured ktlint to your liking). So format runs automatically and can not be disabled.


tx-generator: Use generic JSON instances

This PR adds new generic JSON instances for the tx-generator script language.
The old manual instances are still available in the CLI with the legacy-json command,
and the tx-generator-service still uses the legacy format.

bors r+


1.0.1 Updates

Update to include the following new functionality:

Call to check service status

Changed to 1.1.0 update for these changes


alasql.min.js:10 Uncaught Error: Please include the xlsjs library

Something wrong with the library. i try to upload a XLS files ( EXCEL 97 -2003 workbook) through http://alasql.org/demo/008file/.
It shows an error alasql.min.js:10  Uncaught Error: Please include the xlsjs library
i try to import the xlsx or xls files from cdnjs.com but it seems that it is not support.
importing CSV and XLSX are no problem but not XLS.

The demo is broken.
Please see the wiki about .XLS ( https://github.com/agershun/alasql/wiki/XLS ) and the jsfiddle for example: https://github.com/agershun/alasql/wiki/XLS

Btw: for excel support please use
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/xlsx/0.7.12/xlsx.core.min.js"></script>

I did try that, but it doesn't work for xls format.

It will solve

It shows an error alasql.min.js:10 Uncaught Error: Please include the xlsjs library

i tested it before submitting this issue.

XLS support have been added to the example. Please verify its working now...

the problem is still existed.

hmmmm

Same issue is occuring to me

@mathiasrw  The versions need to be updated in the browser demos.  Here's an updated plnkr of the 008file demo: http://plnkr.co/edit/Atqtg7RKrKbXtJ8eH6Qz?p=info
<script<EMAIL_ADDRESS><script<EMAIL_ADDRESS>

Awesome! I have updated https://github.com/agershun/alasql-org/blob/gh-pages/demo/008file/index.html so the change should be reflected on http://alasql.org/demo/008file/ any time soon

this is my code:
alasql('SELECT * INTO XLSX("test.xlsx",{headers:true}) FROM ?', [vm.areaData])
but......

hi @alexvingg
After using
alasql.utils.isBrowserify = false;
alasql.utils.global.XLSX = XLSX;
I got error: error TS2339: Property 'utils' does not exist on type 'AlaSQL' in my angular application
could you please elaborate about utils in alasql as I did not manage to find any info about them

@lzzattack I had the same problem.
I solved this:
import alasql from 'alasql';
import XLSX from 'xlsx';
alasql.utils.isBrowserify = false;
alasql.utils.global.XLSX = XLSX;

Well done with these configs in Vue. Thanks a lot.

I can confirm this solves the problem in react too


MYC-140 Add to readme required environment variable information & upd…

MYC-140 Add to readme required environment variable information & update .gitignore
Though actually the Agent should have been mocked properly.

As per comments it is not required.


Update index.md with vision statement; add middle initial to name

I added a vision statement and will be creating content to add more to this page. How shall we manage the reviews?

Looks good to me.


Smoke test: Git tests are failing

Maybe related to decorations (@jrieken fyi). I ran them on Linux:

Postponing. This is how far I get when running the smoke-test locally
ieken:~/Code/vscode$ npm run smoketest

><EMAIL_ADDRESS>smoketest /Users/jrieken/Code/vscode
> cd test/smoke && mocha

*** Test data: /var/folders/jh/nmq5w60n2vn_491r573nf0fr0000gn/T/t526477u4UM23h5PH6
*** Preparing smoketest setup...
*** Fetching keybindings...
*** Creating workspace file...
*** Cloning test project repository...
*** Running npm install...
npm WARN deprecated<EMAIL_ADDRESS>Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated<EMAIL_ADDRESS>Deprecated, use jstransformer
added 198 packages in 3.677s
*** Smoketest setup done!

  1) "before all" hook
  2) "after all" hook

  0 passing (31s)
  2 failing

  1)  "before all" hook:
     Error: getHTML with selector [id="workbench.main.container"]: Timed out after 20 seconds.
      at SpectronClient.<anonymous> (out/spectron/client.js:183:31)
      at Generator.next (<anonymous>)
      at fulfilled (out/spectron/client.js:8:58)
      at <anonymous>

  2)  "after all" hook:
     TypeError: Cannot read property 'stop' of undefined
      at Context.<anonymous> (out/main.js:215:24)
      at Generator.next (<anonymous>)
      at out/main.js:11:71
      at new Promise (<anonymous>)
      at __awaiter (out/main.js:7:12)
      at Context.<anonymous> (out/main.js:214:12)

Likely, this needs changes
const name = element.querySelector('.label-name') as HTMLElement;
				const icon = element.querySelector('.monaco-icon-label') as HTMLElement;
				const actionElementList = element.querySelectorAll('.actions .action-label');

Closing... Apparently it did run a few days ago, on some machine surely not on mine which still shows above error


When using -perlevel without specifying -vert, output computes for each slice

This behaviour is counterintuitive. When specifying -perlevel without -vert, metrics should be aggregated within each level, and output should be done per level for all levels.

duplicate of https://github.com/neuropoly/spinalcordtoolbox/issues/2195


Problem in MDF get_bands()

When running the following KRHF calculation with the mixed density fitting:
...
kmf = pbcscf.KRHF(cell, cell.make_kpts([2,2,2])).mix_density_fit()
kmf.with_df.mesh = [10,10,10]
print(kmf.kernel())
...
e_kn_2 = kmf.get_bands(band_kpts)[0]
...

the following error was generated:

Exception in thread Thread-18:
Traceback (most recent call last):
File "/export/apps/Python/2.7.2-CentOS6.0/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/export/apps/Python/2.7.2-CentOS6.0/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "/export/zgid/yanbing/pyscf/pyscf/lib/misc.py", line 699, in qwrap
raise e
RuntimeError: unable to create link (Links: Unable to initialize object)
...
Exception in thread Thread-31:
Traceback (most recent call last):
File "/export/apps/Python/2.7.2-CentOS6.0/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/export/apps/Python/2.7.2-CentOS6.0/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "/export/zgid/yanbing/pyscf/pyscf/lib/misc.py", line 699, in qwrap
raise e
RuntimeError: unable to create link (Links: Unable to initialize object)
...

Traceback (most recent call last):
File "c_mdf.py", line 96, in
e_kn_2 = kmf.get_bands(band_kpts)[0]
File "/export/zgid/yanbing/pyscf/pyscf/pbc/scf/khf.py", line 562, in get_bands
fock = fock + self.get_veff(cell, dm_kpts, kpts=kpts, kpts_band=kpts_band)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/scf/khf.py", line 502, in get_veff
vj, vk = self.get_jk(cell, dm_kpts, hermi, kpts, kpts_band)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/scf/khf.py", line 493, in get_jk
exxdiv=self.exxdiv)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/df/mdf.py", line 343, in get_jk
vk = mdf_jk.get_k_kpts(self, dm, hermi, kpts, kpts_band, exxdiv)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/df/mdf_jk.py", line 77, in get_k_kpts
vk_kpts += df_jk.get_k_kpts(mydf, dm_kpts, hermi, kpts, kpts_band, None)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/df/df_jk.py", line 153, in get_k_kpts
mydf.build(kpts_band=kpts_band)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/df/df.py", line 541, in build
self._make_j3c(self.cell, self.auxcell, kptij_lst, cderi)
File "/export/zgid/yanbing/pyscf/pyscf/pbc/df/mdf.py", line 226, in _make_j3c
feri['j3c-kptij'] = feri['j3c-junk-kptij']
File "/export/apps/Python/2.7.2-CentOS6.0/lib/python2.7/site-packages/h5py/_hl/group.py", line 229, in setitem
h5o.link(obj.id, self.id, name, lcpl=lcpl, lapl=self._lapl)
File "h5o.pyx", line 187, in h5py.h5o.link (h5py/h5o.c:2862)
RuntimeError: unable to create link (Links: Unable to initialize object)

Fixed in commit 1f41ca243f4bc1257c2874cfe3bedde7b935eb6a


Display query error

Is your feature request related to a problem? Please describe.
When a request is done using an invalid query, I want to see the error to fix the query.
For now, it only displays "Error fetching graph data :( Please check your query and try again later".

Describe the solution you'd like
When the query is invalid, I want to see the query error.

@florentc I think this was resolved by #112 ?

No it was not. Not yet.

Querying has been removed.


CI: k8s-1.8 cluster not ready before running preflight checks

CI:  k8s-1.8.K8sHealthTest checks cilium-health status between nodes
In PR #6435 I hit an issue where in the k8s-1.8 VM, the preflight checks failed in the first test run. Inspecting the logs, Cilium has restarted multiple times. The most recent restart contained these final log messages:
2018-12-11T17:48:42.665833416Z level=fatal msg="Unable to connect to kvstore" error="rpc error: code = Unknown desc = " subsys=kvstore
2018-12-11T17:48:42.668942723Z level=fatal msg="Agent pipe unexpectedly closed, shutting down" subsys=cilium-node-monitor

It seems like perhaps the initial bootstrapping in this VM was not complete before starting to run the {preflight checks, tests}. Subsequent tests seem to work fine.
Failure:
Stacktrace
/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:340
cilium pre-flight checks failed
Expected
    <*errors.errorString | 0xc4203c0940>: {
        s: "CiliumPreFlightCheck error: Timeout reached: PreflightCheck failed: Cluster connectivity is unhealthy on 'cilium-76f8g': Exitcode: 255 \nStdout:\n \t \nStderr:\n \t Error: Cannot get status/probe: context deadline exceeded\n\t \n\t command terminated with exit code 255\n\t \n",
    }
to be nil
/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/k8sT/assertionHelpers.go:110
Standard Output
Number of 'context deadline exceeded' in logs: 0
Number of 'level=error' in logs: 0
⚠  Number of 'level=warning' in logs: 7
Number of 'Cilium API handler panicked' in logs: 0
⚠  Number of 'Goroutine took lock for more than' in logs: 40
Cilium pods: [cilium-76f8g cilium-t9bxn]
Netpols loaded:
CiliumNetworkPolicies loaded:
Endpoint Policy Enforcement:
     cilium-etcd-nqhztbf2vc             =>   none
     cilium-etcd-rnp47fkx4t             =>   none
     etcd-operator-696fb6d99-4kwnd      =>   none
     kube-dns-6f4c8dbcd4-7q7jd          =>   none
     prometheus-core-5c9fbf5cc6-27pj6   =>   none
     cilium-etcd-4bpqs7gwhb             =>   none
     cilium-etcd-5rvdrx2mvb             =>   none
     cilium-etcd-hj4k7x76kr             =>   none
Cilium agent 'cilium-76f8g': Status: Ok  Health: Ok Nodes "k8s2 k8s1" ContinerRuntime: Ok Kubernetes: Ok KVstore: Ok Controllers: Total 31 Failed 0
Cilium agent 'cilium-t9bxn': Status: Ok  Health: Ok Nodes "k8s2 k8s1" ContinerRuntime: Ok Kubernetes: Ok KVstore: Ok Controllers: Total 27 Failed 0

Standard Error
STEP: Installing DNS Deployment
STEP: Deploying etcd-operator
STEP: Installing Cilium
STEP: Performing Cilium preflight check
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that cilium-health status is healthy
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that cilium-health status is healthy
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that no controllers in Cilium have failed
STEP: Checking that cilium-health status is healthy
===================== TEST FAILED =====================
cmd: kubectl get pods -o wide --all-namespaces
Exitcode: 0
Stdout:
 	 NAMESPACE     NAME                                   READY     STATUS    RESTARTS   AGE       IP              NODE
	 kube-system   cilium-76f8g                           1/1       Running   4          6m        <IP_ADDRESS>   k8s2
	 kube-system   cilium-etcd-5rvdrx2mvb                 1/1       Running   0          28s       <IP_ADDRESS>     k8s1
	 kube-system   cilium-etcd-nqhztbf2vc                 1/1       Running   0          11s       <IP_ADDRESS>      k8s2
	 kube-system   cilium-etcd-operator-8796fb686-gj2zs   1/1       Running   0          6m        <IP_ADDRESS>   k8s2
	 kube-system   cilium-etcd-rnp47fkx4t                 1/1       Running   0          36s       <IP_ADDRESS>       k8s2
	 kube-system   cilium-t9bxn                           1/1       Running   4          6m        <IP_ADDRESS>   k8s1
	 kube-system   etcd-k8s1                              1/1       Running   0          10m       <IP_ADDRESS>   k8s1
	 kube-system   etcd-operator-696fb6d99-4kwnd          1/1       Running   0          5m        <IP_ADDRESS>     k8s2
	 kube-system   kube-apiserver-k8s1                    1/1       Running   0          9m        <IP_ADDRESS>   k8s1
	 kube-system   kube-controller-manager-k8s1           1/1       Running   0          10m       <IP_ADDRESS>   k8s1
	 kube-system   kube-dns-6f4c8dbcd4-7q7jd              3/3       Running   3          9m        <IP_ADDRESS>      k8s1
	 kube-system   kube-proxy-k29zq                       1/1       Running   0          6m        <IP_ADDRESS>   k8s2
	 kube-system   kube-proxy-klqps                       1/1       Running   0          9m        <IP_ADDRESS>   k8s1
	 kube-system   kube-scheduler-k8s1                    1/1       Running   0          10m       <IP_ADDRESS>   k8s1
	 monitoring    prometheus-core-5c9fbf5cc6-27pj6       1/1       Running   0          6m        <IP_ADDRESS>     k8s2

Stderr:

cmd: kubectl exec -n kube-system cilium-76f8g -- cilium endpoint list
Exitcode: 0
Stdout:
 	 ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                              IPv6                   IPv4          STATUS
	            ENFORCEMENT        ENFORCEMENT
	 14532      Disabled           Disabled          101        k8s:app=etcd                                             f00d::a0a:100:0:5649   <IP_ADDRESS>    ready
	                                                            k8s:etcd_cluster=cilium-etcd
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.cilium/app=etcd-operator
	                                                            k8s:io.kubernetes.pod.namespace=kube-system
	 27025      Disabled           Disabled          26413      k8s:app=prometheus                                       f00d::a0a:100:0:8e2    <IP_ADDRESS>   ready
	                                                            k8s:component=core
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=prometheus-k8s
	                                                            k8s:io.kubernetes.pod.namespace=monitoring
	 29437      Disabled           Disabled          100        k8s:io.cilium.k8s.policy.cluster=default                 f00d::a0a:100:0:73a8   <IP_ADDRESS>   ready
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=cilium-etcd-sa
	                                                            k8s:io.cilium/app=etcd-operator
	                                                            k8s:io.kubernetes.pod.namespace=kube-system
	 49303      Disabled           Disabled          4          reserved:health                                          f00d::a0a:100:0:f5c6   <IP_ADDRESS>    ready
	 63735      Disabled           Disabled          101        k8s:app=etcd                                             f00d::a0a:100:0:be14   <IP_ADDRESS>     ready
	                                                            k8s:etcd_cluster=cilium-etcd
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.cilium/app=etcd-operator
	                                                            k8s:io.kubernetes.pod.namespace=kube-system

Stderr:
 	 level=info msg="Detected MTU 1500" subsys=mtu

cmd: kubectl exec -n kube-system cilium-t9bxn -- cilium endpoint list
Exitcode: 0
Stdout:
 	 ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                        IPv6                 IPv4          STATUS
	            ENFORCEMENT        ENFORCEMENT
	 29704      Disabled           Disabled          102        k8s:io.cilium.k8s.policy.cluster=default           f00d::a0a:0:0:26c    <IP_ADDRESS>    ready
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=kube-dns
	                                                            k8s:io.kubernetes.pod.namespace=kube-system
	                                                            k8s:k8s-app=kube-dns
	 44695      Disabled           Disabled          101        k8s:app=etcd                                       f00d::a0a:0:0:28b6   <IP_ADDRESS>   ready
	                                                            k8s:etcd_cluster=cilium-etcd
	                                                            k8s:io.cilium.k8s.policy.cluster=default
	                                                            k8s:io.cilium.k8s.policy.serviceaccount=default
	                                                            k8s:io.cilium/app=etcd-operator
	                                                            k8s:io.kubernetes.pod.namespace=kube-system
	 61072      Disabled           Disabled          4          reserved:health                                    f00d::a0a:0:0:d6cb   <IP_ADDRESS>    ready

Stderr:
 	 level=info msg="Detected MTU 1500" subsys=mtu

===================== Existing AfterFailed =====================

[[ATTACHMENT|9985ac59_K8sHealthTest_checks_cilium-health_status_between_nodes.zip]]

Link: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/8540/execution/node/96/log/?consoleFull
Zip:
9985ac59_K8sHealthTest_checks_cilium-health_status_between_nodes (1).zip

Likely duplicate of #6370.


Bugfix: exception is now displayed in last failed step when there are multiple failed steps

Related to issue #191 and pull request #352.
Before:

After:

Probably related to pull request #498, which unlocks the possibility to have multiple failures per test case depending on framework and approach used.

The goal of this pull request was to fix a bug described in #431.
I think it's a bug because current behaviour is not what user would expect.
If you don't want to deal with this issue we need (1) document it somewhere where all users can see it and (2) detect situations when this bug can cause generation of incorrect report and provide good error message.

@buzdin Not exactly. #498 does nothing with exceptions leaving it as is.

One of the reasons to delay merging of this request, as I understand from this thread, is that it is assumed as a best practice to have one failure per test case. The pull requests merged some time ago allows having multiple failures on test step level in a single test case. Which means this bug fix makes sense and Allure needs to show failures exactly at the test step it occurred.

@buzdin Are you talking about #352?

closed because https://github.com/allure-framework/allure-core/issues/721


Question about Question Dependency Structure relation

Hello there,
First of all, great work you guys! I'm really excited to understand and evaluate your model on other datasets.
My question is simply: How is Question Dependency Structure relation different from regular self-attention? According to Figure 2 in the paper, it seems that this relation serves the same purpose as vanilla self-attention. Can you expand upon this relation concept?

In fact, the regular self-attention may learn the dependency relation in an implicit way, as we can see in the Table 9 and Table 10, the results can be improved by using relation-aware self-attention, especially for small model.


🚀 Feature: Leveraging GraphQL API in Backstage

🔖 Feature description
Backstage, renowned for its prowess in managing the software development lifecycle, is poised to ascend to new heights with the integration of a GraphQL API. This enhancement not only amplifies the platform's capabilities but also catalyses a paradigm shift towards data-driven development practices. In this proposal, we explore the multifaceted benefits of GraphQL integration, culminating in the creation of service maturity indices and actionable insights, thereby fostering continuous improvement and innovation within organizations.
Benefits of GraphQL Integration:
Flexibility and Efficiency: GraphQL bestows users with unparalleled flexibility in data retrieval, enabling precise queries tailored to specific requirements. This optimized approach streamlines data access and reduces network overhead, fostering efficiency in data retrieval tasks.
Customization and Adaptability: The GraphQL API empowers developers to define and shape data queries dynamically, catering to diverse use cases and evolving requirements. This customization capability ensures adaptability to organizational needs, fostering innovation and agility in development workflows.
Compatibility and Interoperability: Coexisting alongside RESTful endpoints, GraphQL ensures seamless compatibility with existing integration frameworks. This harmonious coexistence promotes interoperability, allowing developers to choose the integration paradigm that best aligns with their needs and preferences.
### Proposed Functionality:
Querying Metadata: The GraphQL API facilitates comprehensive access to Backstage's rich metadata repository, encompassing service descriptions, ownership details, dependencies, and version history. This wealth of information serves as the cornerstone for insightful analytics and decision-making processes.
Managing Entities: Through GraphQL mutations, users gain the ability to create, update, and delete entities programmatically. This administrative prowess simplifies resource management tasks, fostering automation and streamlining operational workflows within Backstage.
Access Control: Implementation of GraphQL-based access control mechanisms ensures granular authorization policies, safeguarding sensitive data and mitigating security risks. By enforcing fine-grained access controls, organizations bolster data security and compliance with regulatory requirements.
Extensibility: The modular and extensible GraphQL schema encourages plugin development and third-party integrations, enriching the Backstage ecosystem with additional functionality. This extensibility fosters innovation and augments the platform's value proposition, catering to diverse user needs and preferences.
### Utilizing Rich Dataset for Service Maturity Index and Insights:
By harnessing the GraphQL API in conjunction with Backstage's comprehensive dataset, organizations unlock a trove of opportunities for advanced analytics and insights:
Defining Service Maturity Metrics: Custom metrics and KPIs are defined to gauge the maturity of services, encompassing factors such as code quality, deployment frequency, and user satisfaction.
Calculating Service Maturity Index: Through GraphQL-powered data aggregation and analysis, a service maturity index is computed for each component or service, providing stakeholders with actionable insights into its current state and areas for improvement.
Identifying Improvement Opportunities: Armed with service maturity indices, teams identify optimization opportunities, driving initiatives to enhance development processes, improve service reliability, and foster innovation.
Building Logic for Continuous Improvement: Sophisticated logic and algorithms are developed atop the Backstage dataset to automate decision-making and facilitate continuous improvement initiatives, paving the way for predictive analytics and data-driven strategies.
Visualization and Reporting: Integration with data visualization tools enables the creation of interactive dashboards and reports, empowering stakeholders with intuitive visual representations of service maturity metrics and development trends.
Conclusion:
The integration of a GraphQL API into Backstage marks a pivotal milestone in its evolution, catalyzing a transformation towards data-driven development practices. By leveraging the rich dataset and analytical capabilities enabled by GraphQL, organizations embark on a journey of continuous improvement, innovation, and agility in their software development endeavors. This holistic approach not only enhances operational efficiency but also fosters a culture of collaboration, empowerment, and excellence within the Backstage community.
🎤 Context
Integrating a GraphQL API into Backstage represents a significant leap forward in managing the software development lifecycle. This enhancement empowers precise data retrieval, fosters agility through customizable queries, and seamlessly integrates with existing systems. Practical applications include querying metadata for strategic insights, automating entity management, enforcing robust access controls, and extending functionality through plugins. Leveraging GraphQL enables advanced analytics like defining service maturity metrics, computing actionable indices, automating workflows, and visualizing trends via interactive dashboards. This integration propels organizations towards data-driven development, enhancing efficiency, innovation, and collaboration across teams.
✌ Possible Implementation
propose the implementation of a GraphQL API within our platform. This integration aims to optimize data retrieval efficiency by enabling precise and tailored queries. It should seamlessly integrate alongside our existing RESTful endpoints, ensuring compatibility and flexibility. Developers will benefit from the ability to dynamically shape data queries, automate entity management tasks, enforce detailed access controls, and extend functionality through customizable plugins. This initiative aims to promote agility, innovation, and a data-centric approach across our software development lifecycle.
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

Hi @amitommishra, it might be worthwhile for you to reach out to those working in this space on the Backstage Discord server. There's actually a dedicated #graphql channel there. I'd also recommend truly interacting with the project as there are some things you mention that are at odds with how Backstage is intended to work. For example your access control section ignores the fact that there is a permission framework.
Hi @taras, I feel like there's lot of prior discussions on this topic, any suggestions here?  Perhaps your plugin would be a good starting point?
https://github.com/thefrontside/playhouse/tree/main/plugins/graphql-backend

Yep GraphQL was something we were aiming for not too long ago. After experimenting a bit more and trying to find a way to ship it as part of the core framework the conclusion was that it doesn't provide a clear benefit to the OSS ecosystem of Backstage plugins and generally just ends up complicating the architecture. We do however think it's still a good fit for higher level internal APIs that might be built on top of the Backstage APIs, and for that purpose there's the GraphQL plugin from Frontside that André linked to.
Seeing as this isn't something we're aiming for right now as part of the core framework, and it has an existing solution, I'm going to close this issue.


off-heap state access and boost fusion

I wanted to see if i could make the java-side build as simple as humanly possible for at least a benchmark cut of opennars to test a notion i have to reify beans into BytebUffer expanses projected onto slabs.
A follow on would be to utilize the slabs as a proto dialect; and build a reference u-tree spirit parser for the narsese grammars for c++ side event interrop with proto to-from java.
https://github.com/jnorthrup/prautobeans is a maven-plugin based proto IDL parserto generate java interface proxies ( GWT Autobeans/Splittable) with bytebuffer backing stores,   a complimentary library https://github.com/jnorthrup/drunken-wallhack is able to map GWT Autobeans to zero-copy json input parsed on the fly -- with two flavors of stateful and attribute-seek-only implementations, both significantly faster than gson at large input.
the first question is:
does mavenization fit the long-term of opennars?
i am for maven because there's potential to bring along some portable and robust c++ artifacts using boost headers-as-libraries in maven compilation, and if any part of that needs help being cleaner i might hack it the way it needs to be upstream in maven-native-plugin if it made sense and enabled other projects to work with this one.  the motorola bluez driver project has immaculate c++ build execution under maven, it's very clean to bring over.

combine with utf8 implemented by int[] buffers , started here
https://github.com/opennars/opennars/blob/volatile5/nars_util/src/main/java/nars/util/utf8/IntBuf.java
https://github.com/opennars/opennars/blob/volatile5/nars_util/src/test/java/objenome/util/IntBufTest.java
utf8 byte[] keys for terms seems to improve both memory usage and also cpu because it reduces comparison and hashing cost. an int[] implementation would add additional cpu improvements, i could not find anything like this in any java utf8 libraries though

public interface Term extends Cloneable, Comparable, Named<byte[]>, Termed, Serializable {
notice the byte[] in Named, this identifies the key type when a Term is used in a Bag

https://github.com/jnorthrup/drunken-wallhack/blob/master/src/main/java/com/colinalworth/gwt/beans/shared/DummySplittable.java#L12
On Thu, May 28, 2015 at 4:34 PM, automenta<EMAIL_ADDRESS>wrote:

public interface Term extends Cloneable, Comparable, Named, Termed,
Serializable {
notice the byte[] in Named, this identifies the key type when a Term is
used in a Bag
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106628981.

i got most of the existing Utf8 / ByteBuf code from Boon JSON parser

i dont see anything that looks like it would move the needle on performance
and apparently backed it out as easily as you brought it in.
bbcursive is in as a placeholder. bbcursive is starting to have analogs of
the bytebuffer operations for BytebufferReader operations, which is a fancy
way of making a class to grab the ByteBuffer pointers and peek/poke
directly on barrier-free RAM.  the jury is out whether you do bypass any
barriers and syncronizers but it cant hurt if you decide to mmap a few gigs
of json assertions as atoms with pointers
On Thu, May 28, 2015 at 7:48 PM, automenta<EMAIL_ADDRESS>wrote:

i got most of the existing Utf8 / ByteBuf code from Boon JSON parser
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106664031.

i doubt anyone is writing java code that outperforms the jdk's native
string handling for utf8.  i could be wrong, but even if they did beat the
jvm for strings, at what cost for what gains?  i beleive that picutre does
change when c++ is part of the runtime, plus or minus actual zero copy
object mapping
On Thu, May 28, 2015 at 9:11 PM, james northrup<EMAIL_ADDRESS>wrote:

i dont see anything that looks like it would move the needle on
performance and apparently backed it out as easily as you brought it in.
bbcursive is in as a placeholder. bbcursive is starting to have analogs of
the bytebuffer operations for BytebufferReader operations, which is a fancy
way of making a class to grab the ByteBuffer pointers and peek/poke
directly on barrier-free RAM.  the jury is out whether you do bypass any
barriers and syncronizers but it cant hurt if you decide to mmap a few gigs
of json assertions as atoms with pointers
On Thu, May 28, 2015 at 7:48 PM, automenta<EMAIL_ADDRESS>wrote:

i got most of the existing Utf8 / ByteBuf code from Boon JSON parser
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106664031.

i use NALPerfLoop to test optimization as a whole. on single thread mode (multithreaded modes, if they still work, arent guaranteed results yet) i generally find < 10uSec / cycle readings on my PC.  this means ~100khz can be expected for the 2k concepts the defaults there are set. i take this to mean APPROX (for various reasons) 50 "narwaves per second"
constructing the strings is part of it. getting the hash is another although standard string handling would include this.  but the other part is re-using the buffer (arraycopy) when constructing a superterm. this seems to add up.  then comparing buffers for equivalence and compareTo, this is where i think the int[] can help. but its not going to provide as much performance as somethign more drastic that will seems like it will require being more clever than just interpreting the profiler output as only i've been doing all along

some easy optimizations: encode the NAL operators as special characters, they are prsently naively stored as their string reprsentation, WITH spaces: " --> " (taking 5 bytes when it could take 1)
SELF is sort of a reserved term, but it could easily be replaced with "I" saving 3 bytes on every occurence
as terms become longer we could use RLE to compress them but im not certain at what threshold this would matter if any

the "Stamp" is a data structure assigned for each Task to prevent cyclic reasoning. currently this uses an array of unique serial #'s, limited by a maximum size, that are compared for overlap. i think another implementation of this that can work would be a Bloom filter (ex: guava's).  It is approximate but so is the finite-length array stamp.  Another advantage of the bloom filter is bitwise operations something to consider.  Anyway I do not think the timing information should be part of the stamp, i will probably move this to Task or its own class, and also occurenceTime to its own subclass to keep it distinct (occurenceTime is not used in 'eternal' pre-NAL7 reasoning).

i acheived 90% of netty performance duplicating the RelaxFactory
single-threaded io loop and feeding new sockets round-robin to the 8
threads for 8 cores.
netty goes to great lengths to rewrite bytebuffer and nio with heap objects
and misc.unsafe;  i think they went to a ton of effort with a  lot of
developers over a long time to get a 10% edge over known latency-inducing
DirtectByteBuffer read access and java UTF_8 for marshalling strings.
for 1xio i pulled 150% performance out of my ass going from 1 thread to 8
and simply reducing, not fully pooling bytebuffer allocations -- slabs are
still gc-tracked heap objects with no finegrained purge options once
threads start divying them up.  allocating them 64 megs + at a time reduces
pressure on the gc.  that aside, 1xio uses a few % less cpu while making
comparable TPS. better buffer and block pooling strategies could bring up a
few more %.
i beleive there is no option for NIO based SSL, only stream based SSL.
that's why 1xio seems to be the only pure select loop driven engine of the
ones i have seen.
the rest try to accomodate adapters and abstractions to all network
scenarios, again, not just a little bit due to SSL Engine being
undocumented garbage with holes and bugs and ancient ciphers.
On Thu, May 28, 2015 at 9:32 PM, automenta<EMAIL_ADDRESS>wrote:

i use NALPerfLoop to test optimization as a whole. on single thread mode
(multithreaded modes, if they still work, arent guaranteed results yet) i
generally find < 10uSec / cycle readings on my PC. this means ~100khz can
be expected for the 2k concepts the defaults there are set. i take this to
mean APPROX (for various reasons) 50 "narwaves per second"
constructing the strings is part of it. getting the hash is another
although standard string handling would include this. but the other part is
re-using the buffer (arraycopy) when constructing a superterm. this seems
to add up. then comparing buffers for equivalence and compareTo, this is
where i think the int[] can help. but its not going to provide as much
performance as somethign more drastic that will seems like it will require
being more clever than just interpreting the profiler output as only i've
been doing all along
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106682185.

oh, so, those slabs are in the bbcursive addition to nars-logic in my fork
now
ill push the branch up
On Thu, May 28, 2015 at 10:02 PM, james northrup<EMAIL_ADDRESS>wrote:

i acheived 90% of netty performance duplicating the RelaxFactory
single-threaded io loop and feeding new sockets round-robin to the 8
threads for 8 cores.
netty goes to great lengths to rewrite bytebuffer and nio with heap
objects and misc.unsafe;  i think they went to a ton of effort with a  lot
of developers over a long time to get a 10% edge over known
latency-inducing DirtectByteBuffer read access and java UTF_8 for
marshalling strings.
for 1xio i pulled 150% performance out of my ass going from 1 thread to 8
and simply reducing, not fully pooling bytebuffer allocations -- slabs are
still gc-tracked heap objects with no finegrained purge options once
threads start divying them up.  allocating them 64 megs + at a time reduces
pressure on the gc.  that aside, 1xio uses a few % less cpu while making
comparable TPS. better buffer and block pooling strategies could bring up a
few more %.
i beleive there is no option for NIO based SSL, only stream based SSL.
that's why 1xio seems to be the only pure select loop driven engine of the
ones i have seen.
the rest try to accomodate adapters and abstractions to all network
scenarios, again, not just a little bit due to SSL Engine being
undocumented garbage with holes and bugs and ancient ciphers.
On Thu, May 28, 2015 at 9:32 PM, automenta<EMAIL_ADDRESS>wrote:

i use NALPerfLoop to test optimization as a whole. on single thread mode
(multithreaded modes, if they still work, arent guaranteed results yet) i
generally find < 10uSec / cycle readings on my PC. this means ~100khz can
be expected for the 2k concepts the defaults there are set. i take this to
mean APPROX (for various reasons) 50 "narwaves per second"
constructing the strings is part of it. getting the hash is another
although standard string handling would include this. but the other part is
re-using the buffer (arraycopy) when constructing a superterm. this seems
to add up. then comparing buffers for equivalence and compareTo, this is
where i think the int[] can help. but its not going to provide as much
performance as somethign more drastic that will seems like it will require
being more clever than just interpreting the profiler output as only i've
been doing all along
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106682185.

ive hesitated to go further with multithreading an individual NAR reasoner. it can be done but if the "Default" control loop and bags are directly converted to multithreading the performance will ultimatley decrease due to synchronization, locking etc. the alternate control loops are not tested but eliminate some or all of the contention.  however multithreading at the inter-NAR level seems to be the most flexible option once we learn how to appropriately divide the work. for example, a combination of high frequency and low frequency NARs operating on different scales, sharing data in some way (I/O messages, tasks, or entire concepts). all of this is unexplored as far as i know

the most unique and untested of the control strategies is the 'Ant' model where each thread directly processes a concept and moving to an adjacent one (decided by some local heuristic which can approximate the nature of the global Bag). this elimnates a central bag as long as two threads don't work on the same concept at once. if activation is accumulated between cycles as it should be doing now then this should also work fine for DirectProcess (whcih should probably be renamed TaskProcess since it is like the Task-level analog of a ConceptProcess). anyway the ant model might allow large large memories with many threads https://github.com/opennars/opennars/blob/volatile5/nars_logic/src/main/java/nars/model/cycle/experimental/AntCore.java

another model is Solid https://github.com/opennars/opennars/blob/volatile5/nars_logic/src/main/java/nars/model/impl/Solid.java which is the more predictable of them all because it applies a uniform policy to all concepts each cycle. this could be generalized to apply to a fraction P of all concepts per cycle and then for smaller values of P it would behave like Default control cycle with a Bag

Solid sounds like the gpu winner
On Thu, May 28, 2015 at 10:30 PM, automenta<EMAIL_ADDRESS>wrote:

another model is Solid
https://github.com/opennars/opennars/blob/volatile5/nars_logic/src/main/java/nars/model/impl/Solid.java
which is the more predictable of them all because it applies a uniform
policy to all concepts each cycle. this could be generalized to apply to a
fraction P of all concepts per cycle and then for smaller values of P it
would behave like Default control cycle with a Bag
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106694446.

yah but all things considered i havent found much that is vector parallelizable which could be separated from cpu logic interacting with memory.  probably the best mix would be the hybrid CPU/GPU chips which hopefully java 9 is supposed to vectorize for. until then maybe https://github.com/pcpratts/rootbeer-ex can provide something.
we have been wondering if it would be worth it to use FPGAs to run NARS-customized JVM cores in parallel.  several JVM-sized cores should fit on a commodity FPGA already.  google "jvm fpga" for some papers and http://www.jopdesign.com/ . but i dont think we've hit the limit yet for CPU on a single reasoner, combined with the potential for inter-NAR architectures for distributed processing (which i would like us to solve for p2p mesh first to guarantee mutually assured dissolution of authority, and not the easier cluster scenarios that a consolidated power would likely amass)
iirc, dr. wang has briefly described hardware implementations of NARS in some papers.  in some ways, each "Concept" can be considered a mini or virtual processor.

but in practice we'll likely want to save GPU and some cpu threads for external processes which NARS can invoke externally without its own micro-managing. eventually to include compiled procedures generated as a product of reasoning
https://github.com/opennars/opennars/blob/volatile5/nars_lab/src/main/java/nars/rl/lstm/SimpleLSTM.java
https://github.com/opennars/opennars/blob/volatile5/nars_util/src/main/java/nars/util/signal/Autoencoder.java
https://github.com/opennars/opennars/blob/volatile5/nars_lab/src/main/java/nars/rl/AbstractHaiQBrain.java

Some GPU assistance for nars would be a great investment because not everybody has idling FPGA's laying around :D
But yes, the GPU/CPU/whatever utilisation is a tradeoff.
I think that the usual NAL processing core logic don't map that well to an GPU, mainly because of either memory allocation or latency, we can still experiment around.
We just can experiment with GPU's for now...

aparapi is passable for spot optimizations.
what interests me is an excuse to play with Haswell Transactional locking
instructions though i bought one that might be microcode-disabled now.
this would favor Ant model i think to keep cores in-context processing
streams
what also seems like an outcome over some pretty far mountains is to port
nars to STL, for which i think alignment is pretty high.  having c++
mementos opens up the door for amp c++ and openal compilation models for
transactional memory and gpu code emitters.

On Fri, May 29, 2015 at 11:18 AM, james northrup<EMAIL_ADDRESS>wrote:

openal

s/openal/openacc/
Compiler support[edit
http://en.wikipedia.org/w/index.php?title=OpenACC&action=edit&section=1]
Support of OpenACC is available in commercial compilers from PGI (from
version 12.6), Cray, and CAPS.[7]
http://en.wikipedia.org/wiki/OpenACC#cite_note-isc12-7[9]
http://en.wikipedia.org/wiki/OpenACC#cite_note-9[10]
http://en.wikipedia.org/wiki/OpenACC#cite_note-10
OpenUH[11] http://en.wikipedia.org/wiki/OpenACC#cite_note-11 is an Open64
http://en.wikipedia.org/wiki/Open64 based open source OpenACC compiler
supporting C and FORTRAN, developed by HPCTools group from University of
Houston http://en.wikipedia.org/wiki/University_of_Houston.
The OpenARC compiler[12] http://en.wikipedia.org/wiki/OpenACC#cite_note-12 is
an open source, C language
http://en.wikipedia.org/wiki/C_(programming_language) compiler developed
over the past several years at Oak Ridge National Laboratory
http://en.wikipedia.org/wiki/Oak_Ridge_National_Laboratory to fully
support all features in the OpenACC 1.0 specification.
An open source compiler, accULL, is also developed by the University of La
Laguna http://en.wikipedia.org/wiki/University_of_La_Laguna (C language
http://en.wikipedia.org/wiki/C_(programming_language) only).[13]
http://en.wikipedia.org/wiki/OpenACC#cite_note-13
GNU GCC http://en.wikipedia.org/wiki/GNU_Compiler_Collection supports
OpenACC starting with GCC version 5.[14]
http://en.wikipedia.org/wiki/OpenACC#cite_note-14[15]
http://en.wikipedia.org/wiki/OpenACC#cite_note-15

I am as always in a dreaming state, but what about this:
We can build a project to translate automatically a input Language (take Java) to an AST.
In a first stage the transformator can translate the AST to a target language, lets say C++ or D or Java.
Later we can add functionality for automated refactoring and or supercompilation.

in terms of actual results i think the most benefit will come from improvement control system designs regardless of the implementation. but to find these we may need to do intensive searches through parameter spaces driven by evolutionary algorithms and other optimization tools (the reason for the "objenome" tools). this can be easily distributed in a "nars@home" sort of crowdsourced effort. https://github.com/opennars/opennars/blob/volatile5/nars_logic/src/test/java/nars/analyze/experimental/OptimizeLeakGenetic3.java is one example for evolving a budget control function with 6 input variables. slightly overkill but illustrates an example of attempting to optimize one isolated feature that could result in a huge benefit. for example if it found that applying a X% negative bias towards derivations involving a ImageExt produced Y% cycle-sooner results as measured by test case completion, etc..

actually, 9 variables:
Input task priority
derPri = leakProgram.var("derPri");
Input task quality
derQua = leakProgram.var("derQua");
Task is a quest or question (1) or not (0)
derQuest = leakProgram.var("derQuest");
Task is a belief (1) or not (0)
derJudge = leakProgram.var("derJudge");
Task is a goal (1) or not (0)
derGoal = leakProgram.var("derGoal");
Complexity of the task
derComplex = leakProgram.var("derComplex");
Histogram of priority distribution of concept bag between bottom quarter and 1st third
c0 = leakProgram.var("c0");
Histogram of priority distribution of concept bag between 1st third and 2nd third
c1 = leakProgram.var("c1");
Histogram of priority distribution of concept bag between 2nd third and top
c2 = leakProgram.var("c2");
the c0,c1,c2 give the function a sense of the current distribution of concepts in the bag which it will be attempting to insert the new task into. the output of this function is the final priority that would be assigned to the incoming task before it is input to memory.
adding additional variables for the term type and other task or system characteristics is where i think this could make some interesting distinctions.

example output:
https://gist.github.com/automenta/e26abe0b664145d72757

i experimentally replaced the byte[] naming with WantzZeroCopy interfaces.  everywhere a byte[] used to be returned now returns a lambda with a bytebuffer method.  this means that all name() calls are deferred if desired, cached if desired, and will not materialize if the lambda is what produces the compound strings, until that string needs reading.

wow cool that might be a good way to do it. will check it out soon

my branch is just a bridge i don't expect to see any improvements by adding
slower directmemory options until the object model is pointers to structs
On Fri, May 29, 2015 at 5:20 PM, automenta<EMAIL_ADDRESS>wrote:

wow cool that might be a good way to do it. will check it out soon
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106966242.

is there any reason not to pull this WantsZeroCopy into the code now, or is it better to wait?

give it a shake see what happens i think its a midpoint but i dont plan to
knowingly change NARS semantics just bend some interfaces over time
On Fri, May 29, 2015 at 7:01 PM, automenta<EMAIL_ADDRESS>wrote:

is there any reason not to pull this WantsZeroCopy into the code now, or
is it better to wait?
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106974067.

with regards to bbcursive where WantsZeroCopy is defined, it is integral to
the bbcursive std.{cat,str} methods.
WantsZeroCopy provides no compareTo yet. seems cheap to wrap as a default
method.
"std.cat" needs cat(byte[]...a) operators it only knows WantZeroCopy,
byteBuffers, and ByteBufferReaders to date.  Relaxfactory was the first
bbcursive project and it never had any byte[] operators to write macros for
On Sat, May 30, 2015 at 1:01 PM, james northrup<EMAIL_ADDRESS>wrote:

give it a shake see what happens i think its a midpoint but i dont plan to
knowingly change NARS semantics just bend some interfaces over time
On Fri, May 29, 2015 at 7:01 PM, automenta<EMAIL_ADDRESS>wrote:

is there any reason not to pull this WantsZeroCopy into the code now, or
is it better to wait?
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-106974067.

i suspect the deferred instantiation should help in cases where the term is discarded before being used in a bag, this was the idea behind the different Compound subclasses , some of which implement this halfway or never need to create a byte[] name.  but your abstraction might be cleaner than how these subclasses currently are responsible for it. anyway we can try both and see. do you see any reason not to try the int[] utf8 implementation that i started?

why is a String not good enough here? because of heap ?  byte[] code can't
exist as struct projections on windowed mmap blocks which is where i
suspect scale is easiest to bring in
On Sat, May 30, 2015 at 1:14 PM, automenta<EMAIL_ADDRESS>wrote:

i suspect the deferred instantiation should help in cases where the term
is discarded before being used in a bag, this was the idea behind the
different Compound subclasses , some of which implement this halfway or
never need to create a byte[] name. but your abstraction might be cleaner
than how these subclasses currently are responsible for it. anyway we can
try both and see. do you see any reason not to try the int[] utf8
implementation that i started?
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107081065.

did you have a benchmark in mind?  the drunken-wallhack consumeString()
method  parses quoted json strings and json is explicitly utf-8.
the IntBuffer could be tested in that benchmark to parse between legally
escaping json string quotes
On Sat, May 30, 2015 at 7:48 PM, james northrup<EMAIL_ADDRESS>wrote:

why is a String not good enough here? because of heap ?  byte[] code can't
exist as struct projections on windowed mmap blocks which is where i
suspect scale is easiest to bring in
On Sat, May 30, 2015 at 1:14 PM, automenta<EMAIL_ADDRESS>wrote:

i suspect the deferred instantiation should help in cases where the term
is discarded before being used in a bag, this was the idea behind the
different Compound subclasses , some of which implement this halfway or
never need to create a byte[] name. but your abstraction might be cleaner
than how these subclasses currently are responsible for it. anyway we can
try both and see. do you see any reason not to try the int[] utf8
implementation that i started?
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107081065.

a compareTo and equals() and hashCode with UTF8 int[] would theoretically be 4x faster than UTF16 string.  this is used in ordering subterms in commutative terms like Similarity.  byte[] for UTF8 saves up to 2x memory for term id's, which are used in all tasks (and sentences) and concepts.  int[] would save almost as much, costing up to 3 bytes penalty if length mod 4 bytes == 1 but i think this is acceptable for the comparison and hash benefits.
the benchmark i would use is the NALPerfLoop set to a high # of repetitions for accuracy. then comparing the results on each test and see if there is an overall benefit or if it is specific to certain tests.

you know that all math is promoted to int right?  for base64, the byte[]
option is twice as fast as the char[] option, due strictly to io.  they
both use int promoted math to do the base64 stuff.
http://iharder.sourceforge.net/current/java/base64/
On Sun, May 31, 2015 at 5:32 AM, automenta<EMAIL_ADDRESS>wrote:

a compareTo and equals() and hashCode with UTF8 int[] would theoretically
be 4x faster than UTF16 string. this is used in ordering subterms in
commutative terms like Similarity. byte[] for UTF8 saves up to 2x memory
for term id's, which are used in all tasks (and sentences) and concepts.
int[] would save almost as much, costing up to 3 bytes penalty if length
mod 4 bytes == 1 but i think this is acceptable for the comparison and hash
benefits.
the benchmark i would use is the NALPerfLoop set to a high # of
repetitions for accuracy. then comparing the results on each test and see
if there is an overall benefit or if it is specific to certain tests.
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107171359.

http://migbase64.sourceforge.net/ is the impl that benches both char and
byte versions
On Sun, May 31, 2015 at 9:06 AM, james northrup<EMAIL_ADDRESS>wrote:

you know that all math is promoted to int right?  for base64, the byte[]
option is twice as fast as the char[] option, due strictly to io.  they
both use int promoted math to do the base64 stuff.
http://iharder.sourceforge.net/current/java/base64/
On Sun, May 31, 2015 at 5:32 AM, automenta<EMAIL_ADDRESS>wrote:

a compareTo and equals() and hashCode with UTF8 int[] would theoretically
be 4x faster than UTF16 string. this is used in ordering subterms in
commutative terms like Similarity. byte[] for UTF8 saves up to 2x memory
for term id's, which are used in all tasks (and sentences) and concepts.
int[] would save almost as much, costing up to 3 bytes penalty if length
mod 4 bytes == 1 but i think this is acceptable for the comparison and hash
benefits.
the benchmark i would use is the NALPerfLoop set to a high # of
repetitions for accuracy. then comparing the results on each test and see
if there is an overall benefit or if it is specific to certain tests.
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107171359.

maybe it wouldnt matter so much if java had an Arraycompare (wrapper for
memcmp) like it does Arraycopy. but equivalence (ie. irregardless of hash)
and compareTo ordinality involving int[x] seem like it should beat
byte[x*4] everytime. there is some code in there for an unsafe UTF8 byte[]
comparison involving an int cast but after i suspected a problem with it, i
commented it out. the pure java version of it it didnt seem to have less
performance anyway
On Sun, May 31, 2015 at 12:12 PM, Jim Northrup<EMAIL_ADDRESS>wrote:

http://migbase64.sourceforge.net/ is the impl that benches both char and
byte versions
On Sun, May 31, 2015 at 9:06 AM, james northrup<EMAIL_ADDRESS>wrote:

you know that all math is promoted to int right? for base64, the byte[]
option is twice as fast as the char[] option, due strictly to io. they
both use int promoted math to do the base64 stuff.
http://iharder.sourceforge.net/current/java/base64/
On Sun, May 31, 2015 at 5:32 AM, automenta<EMAIL_ADDRESS>wrote:

a compareTo and equals() and hashCode with UTF8 int[] would
theoretically
be 4x faster than UTF16 string. this is used in ordering subterms in
commutative terms like Similarity. byte[] for UTF8 saves up to 2x memory
for term id's, which are used in all tasks (and sentences) and concepts.
int[] would save almost as much, costing up to 3 bytes penalty if length
mod 4 bytes == 1 but i think this is acceptable for the comparison and
hash
benefits.
the benchmark i would use is the NALPerfLoop set to a high # of
repetitions for accuracy. then comparing the results on each test and
see
if there is an overall benefit or if it is specific to certain tests.
—
Reply to this email directly or view it on GitHub
<https://github.com/opennars/opennars/issues/37#issuecomment-107171359
.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107213472.

a subset of the jvm options
http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html
-XX:+UseLargePagesUse large page memory. (Introduced in 5.0 update 5.) For
details, see Java Support for Large Memory Pages
http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
.-XX:+UseMPSSUse Multiple Page Size Support w/4mb pages for the heap. Do
not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0
update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]
-XX:+UseStringCacheEnables caching of commonly allocated strings.
-XX:AllocatePrefetchLines=1Number of cache lines to load after the last
object allocation using prefetch instructions generated in JIT compiled
code. Default values are 1 if the last allocated object was an instance and
3 if it was an array.
-XX:AllocatePrefetchStyle=1Generated code style for prefetch instructions.
0 - no prefetch instructions are generated,
1 - execute prefetch instructions after each allocation,
2 - use TLAB allocation watermark pointer to gate when prefetch
instructions are executed.
-XX:+UseCompressedStringsUse a byte[] for Strings which can be represented
as pure ASCII. (Introduced in Java 6 Update 21 Performance Release)
-XX:+OptimizeStringConcatOptimize String concatenation operations where
possible. (Introduced in Java 6 Update 20)
includes -XX:+UseLargePagesUse large page memory. (Introduced in 5.0
update 5.) For details, see Java Support for Large Memory Pages
http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
.-XX:+UseMPSSUse Multiple Page Size Support w/4mb pages for the heap. Do
not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0
update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]
-XX:+UseStringCacheEnables caching of commonly allocated strings.
-XX:AllocatePrefetchLines=1Number of cache lines to load after the last
object allocation using prefetch instructions generated in JIT compiled
code. Default values are 1 if the last allocated object was an instance and
3 if it was an array.
-XX:AllocatePrefetchStyle=1Generated code style for prefetch instructions.
0 - no prefetch instructions are generated,
1 - execute prefetch instructions after each allocation,
2 - use TLAB allocation watermark pointer to gate when prefetch
instructions are executed.
-XX:+UseCompressedStringsUse a byte[] for Strings which can be represented
as pure ASCII. (Introduced in Java 6 Update 21 Performance Release)
-XX:+OptimizeStringConcatOptimize String concatenation operations where
possible. (Introduced in Java 6 Update 20)
On Sun, May 31, 2015 at 11:44 AM, automenta<EMAIL_ADDRESS>wrote:

maybe it wouldnt matter so much if java had an Arraycompare (wrapper for
memcmp) like it does Arraycopy. but equivalence (ie. irregardless of hash)
and compareTo ordinality involving int[x] seem like it should beat
byte[x*4] everytime. there is some code in there for an unsafe UTF8 byte[]
comparison involving an int cast but after i suspected a problem with it, i
commented it out. the pure java version of it it didnt seem to have less
performance anyway
On Sun, May 31, 2015 at 12:12 PM, Jim Northrup<EMAIL_ADDRESS>wrote:

http://migbase64.sourceforge.net/ is the impl that benches both char and
byte versions
On Sun, May 31, 2015 at 9:06 AM, james northrup <
<EMAIL_ADDRESS>wrote:

you know that all math is promoted to int right? for base64, the byte[]
option is twice as fast as the char[] option, due strictly to io. they
both use int promoted math to do the base64 stuff.
http://iharder.sourceforge.net/current/java/base64/
On Sun, May 31, 2015 at 5:32 AM, automenta<EMAIL_ADDRESS>wrote:

a compareTo and equals() and hashCode with UTF8 int[] would
theoretically
be 4x faster than UTF16 string. this is used in ordering subterms in
commutative terms like Similarity. byte[] for UTF8 saves up to 2x
memory
for term id's, which are used in all tasks (and sentences) and
concepts.
int[] would save almost as much, costing up to 3 bytes penalty if
length
mod 4 bytes == 1 but i think this is acceptable for the comparison and
hash
benefits.
the benchmark i would use is the NALPerfLoop set to a high # of
repetitions for accuracy. then comparing the results on each test and
see
if there is an overall benefit or if it is specific to certain tests.
—
Reply to this email directly or view it on GitHub
<
https://github.com/opennars/opennars/issues/37#issuecomment-107171359
.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107213472.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107232995.

me@xyz ~/s/traytention> java -XX:+UseCompressedStrings
Unrecognized VM option 'UseCompressedStrings'
this might do it but its missing in java 8

java -XX:+PrintFlagsFinal

https://github.com/opennars/opennars/blob/volatile5/doc/opennars_entities.svg this shows some of the relations between the main entities involved
i'll try making one to show the Default control feedback loop of how budget selects the premises which derive new tasks that become new input

http://stackoverflow.com/a/15840307 answer is consistent with what i would
attack last, which is once bags are serialized to byte-extents then the
runtime kb state would trie-ify the keys along the lines of HAT-TRIES for
immutable strings(as utf8).  at least where it turned out that memory
access and context/fetch overheads are pathological after all other
profilling unhides it.
On Sun, May 31, 2015 at 1:17 PM, automenta<EMAIL_ADDRESS>wrote:

https://github.com/opennars/opennars/blob/volatile5/doc/opennars_entities.svg
this shows some of the relations between the main entities involved
i'll try making one to show the Default control feedback loop of how
budget selects the premises which derive new tasks that become new input
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107241235.

WantsZeroCopy was just a practice run i don't see it bering a feature that's distinct against prautobeans implicit zero-copy options and lazy iteration.
what comes next is to convert the class hierarchy
from

and to

into a src/main/proto/nars.proto with generator.  then the same places that were modified for WantsZeroCopy key maniuplation will need to support the generated interfaces.  semantics should not change, but i have seen at least one static singleton map that will provoke a discussion of re-entrant practices

some results, cycle speed seems to have improved from the new Identifier
implementation
further gains for internal identifier processing seem possible by removing
the spaces and representing all NAL operators as one character special
symbols.
/home/me/share/opennars/nal/test5/nal5.0.nal: : 86.441ms/test, -63702.527
kb/test, 2.821 uS/cycle, 10214.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.1.nal: : 157.59ms/test, 25660.281
kb/test, 5.023 uS/cycle, 10457.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.10.nal: : 149.849ms/test, -41994.766
kb/test, 4.924 uS/cycle, 10145.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.11.nal: : 159.41ms/test, 18223.73
kb/test, 5.184 uS/cycle, 10251.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.12.nal: : 95.187ms/test, 14318.875
kb/test, 3.146 uS/cycle, 10086.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.13.nal: : 121.945ms/test, -47387.438
kb/test, 4.013 uS/cycle, 10129.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.14.nal: : 102.851ms/test, 17528.281
kb/test, 3.402 uS/cycle, 10078.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.15.nal: : 85.258ms/test, 12519.77
kb/test, 2.74 uS/cycle, 10372.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.16.nal: : 127.144ms/test, 22929.312
kb/test, 4.038 uS/cycle, 10496.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.17.nal: : 114.883ms/test, -37550.234
kb/test, 3.698 uS/cycle, 10356.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.1.nal: : 95.872ms/test, 10450.812
kb/test, 3.026 uS/cycle, 10560.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.2.nal: : 87.685ms/test, 12773.215
kb/test, 2.906 uS/cycle, 10058.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.3.nal: : 100.188ms/test, 9290.609
kb/test, 3.219 uS/cycle, 10375.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.4.nal: : 105.504ms/test,
17930.738 kb/test, 3.403 uS/cycle, 10335.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.nal: : 134.105ms/test, 19051.367
kb/test, 4.238 uS/cycle, 10547.0 cycles/test
/home/me/share/opennars/nal/test5/depr/nal5.19.nal: : 107.836ms/test,
19439.734 kb/test, 3.411 uS/cycle, 10539.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.2.nal: : 128.916ms/test, 24838.094
kb/test, 4.198 uS/cycle, 10236.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.20.nal: : 83.279ms/test, 5196.285
kb/test, 2.694 uS/cycle, 10304.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.21.nal: : 107.98ms/test, 11430.598
kb/test, 3.477 uS/cycle, 10353.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.22.nal: : 71.338ms/test, 7274.375
kb/test, 2.318 uS/cycle, 10257.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.23.nal: : 100.059ms/test, -34401.922
kb/test, 3.186 uS/cycle, 10467.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.24.nal: : 84.691ms/test, 14046.887
kb/test, 2.722 uS/cycle, 10371.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.1.nal: : 84.936ms/test, 15050.227
kb/test, 2.816 uS/cycle, 10053.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.nal: : 84.835ms/test, 14514.5
kb/test, 2.784 uS/cycle, 10157.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.26.nal: : 111.028ms/test, -32310.324
kb/test, 3.673 uS/cycle, 10077.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.27.nal: : 109.6ms/test, 16771.738
kb/test, 3.519 uS/cycle, 10382.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.28.nal: : 111.241ms/test, -31039.051
kb/test, 3.542 uS/cycle, 10469.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.29.nal: : 99.578ms/test, 14417.066
kb/test, 3.156 uS/cyc
On Tue, Jun 2, 2015 at 2:21 AM, Jim Northrup<EMAIL_ADDRESS>wrote:

WantsZeroCopy was just a practice run i don't see it bering a feature
that's distinct against prautobeans implicit zero-copy options and lazy
iteration.
what comes next is to convert the class hierarchy
from
[image: image]
https://cloud.githubusercontent.com/assets/73514/7929537/131543c8-08b4-11e5-9a19-c2c7b9ac5cbb.png
and to
[image: image]
https://cloud.githubusercontent.com/assets/73514/7929527/fc790f8c-08b3-11e5-91d5-ed10a96239c2.png
into a src/main/proto/nars.proto with generator. then the same places that
were modified for WantsZeroCopy key maniuplation will need to support the
generated interfaces. semantics should not change, but i have seen at least
one static singleton map that will provoke a discussion of re-entrant
practices
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107824189.

foo.split( " *--> *" ) wfm
String[] is as good a key imho as String
On Tue, Jun 2, 2015 at 12:30 AM, automenta<EMAIL_ADDRESS>wrote:

some results, cycle speed seems to have improved from the new Identifier
implementation
further gains for internal identifier processing seem possible by removing
the spaces and representing all NAL operators as one character special
symbols.
/home/me/share/opennars/nal/test5/nal5.0.nal: : 86.441ms/test, -63702.527
kb/test, 2.821 uS/cycle, 10214.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.1.nal: : 157.59ms/test, 25660.281
kb/test, 5.023 uS/cycle, 10457.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.10.nal: : 149.849ms/test, -41994.766
kb/test, 4.924 uS/cycle, 10145.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.11.nal: : 159.41ms/test, 18223.73
kb/test, 5.184 uS/cycle, 10251.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.12.nal: : 95.187ms/test, 14318.875
kb/test, 3.146 uS/cycle, 10086.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.13.nal: : 121.945ms/test, -47387.438
kb/test, 4.013 uS/cycle, 10129.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.14.nal: : 102.851ms/test, 17528.281
kb/test, 3.402 uS/cycle, 10078.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.15.nal: : 85.258ms/test, 12519.77
kb/test, 2.74 uS/cycle, 10372.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.16.nal: : 127.144ms/test, 22929.312
kb/test, 4.038 uS/cycle, 10496.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.17.nal: : 114.883ms/test, -37550.234
kb/test, 3.698 uS/cycle, 10356.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.1.nal: : 95.872ms/test, 10450.812
kb/test, 3.026 uS/cycle, 10560.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.2.nal: : 87.685ms/test, 12773.215
kb/test, 2.906 uS/cycle, 10058.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.3.nal: : 100.188ms/test, 9290.609
kb/test, 3.219 uS/cycle, 10375.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.4.nal: : 105.504ms/test,
17930.738 kb/test, 3.403 uS/cycle, 10335.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.nal: : 134.105ms/test, 19051.367
kb/test, 4.238 uS/cycle, 10547.0 cycles/test
/home/me/share/opennars/nal/test5/depr/nal5.19.nal: : 107.836ms/test,
19439.734 kb/test, 3.411 uS/cycle, 10539.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.2.nal: : 128.916ms/test, 24838.094
kb/test, 4.198 uS/cycle, 10236.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.20.nal: : 83.279ms/test, 5196.285
kb/test, 2.694 uS/cycle, 10304.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.21.nal: : 107.98ms/test, 11430.598
kb/test, 3.477 uS/cycle, 10353.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.22.nal: : 71.338ms/test, 7274.375
kb/test, 2.318 uS/cycle, 10257.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.23.nal: : 100.059ms/test, -34401.922
kb/test, 3.186 uS/cycle, 10467.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.24.nal: : 84.691ms/test, 14046.887
kb/test, 2.722 uS/cycle, 10371.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.1.nal: : 84.936ms/test, 15050.227
kb/test, 2.816 uS/cycle, 10053.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.nal: : 84.835ms/test, 14514.5
kb/test, 2.784 uS/cycle, 10157.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.26.nal: : 111.028ms/test, -32310.324
kb/test, 3.673 uS/cycle, 10077.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.27.nal: : 109.6ms/test, 16771.738
kb/test, 3.519 uS/cycle, 10382.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.28.nal: : 111.241ms/test, -31039.051
kb/test, 3.542 uS/cycle, 10469.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.29.nal: : 99.578ms/test, 14417.066
kb/test, 3.156 uS/cyc
On Tue, Jun 2, 2015 at 2:21 AM, Jim Northrup<EMAIL_ADDRESS>wrote:

WantsZeroCopy was just a practice run i don't see it bering a feature
that's distinct against prautobeans implicit zero-copy options and lazy
iteration.
what comes next is to convert the class hierarchy
from
[image: image]
<
https://cloud.githubusercontent.com/assets/73514/7929537/131543c8-08b4-11e5-9a19-c2c7b9ac5cbb.png
and to
[image: image]
<
https://cloud.githubusercontent.com/assets/73514/7929527/fc790f8c-08b3-11e5-91d5-ed10a96239c2.png
into a src/main/proto/nars.proto with generator. then the same places
that
were modified for WantsZeroCopy key maniuplation will need to support the
generated interfaces. semantics should not change, but i have seen at
least
one static singleton map that will provoke a discussion of re-entrant
practices
—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107824189.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107839533.

we can try them all out as subclasses of Identifier. they just need to
implement a few methods and use consistent types between similarly typed
objects.
i've identified several differnent methods of hash, equality, and compareTo
testing for the various entities in NARS.   the two main kinds are either
involving generation of a string-like token (as is represented in byte[]
currently) or by directly comparing the data components of the entities
involved.
for example, sometimes it seems better for a 2-subterm compound to avoid
generating a byte[] name (as long as possible or indefinitely) and instead
just compare the 2 subterms against the other 2-subterm compound.
hashing is usually unavoidable once an item must be bagged, but it can be
calculated by both these 2 methods too, in 2 diferent ways.  (multiple
hashing functions should help with a customized version of CuckooHashmap,
which must hash up to 3 times for get and put.  if it can use a
pre-existing set of hashes instead of its custom hash function that lack
entropy since it only uses the original hashcode.. then it should be faster
and hash better).  even though cuckoohash put and get are slower than
hashmap, i continue to see its benefits of not allocating hash nodes.
btw do you know of a HashMap like collection which recycles its hash nodes
in a pool? i might write one using my DDList doubly-linked list collection
i use in bags. DDList is a linked list where each cell holds a reference to
some item. i use these as values in the index hashmap of a bag. this allows
both sequential cyclical prioritized access and direct removal by ID. i
pool these DD cells into an arraydeque and no allocation has to happen
(bags are generally of fixed size).
https://github.com/opennars/opennars/blob/volatile5/nars_logic/src/main/java/nars/bag/impl/experimental/ChainBag.java
heuristics to choose all the parameters of these conditions and thresholds
for these policies can be tuned by parameter search to minimize cpu,
memory, or etc..
On Tue, Jun 2, 2015 at 12:13 PM, Jim Northrup<EMAIL_ADDRESS>wrote:

foo.split( " *--> *" ) wfm
String[] is as good a key imho as String
On Tue, Jun 2, 2015 at 12:30 AM, automenta<EMAIL_ADDRESS>wrote:

some results, cycle speed seems to have improved from the new Identifier
implementation
further gains for internal identifier processing seem possible by
removing
the spaces and representing all NAL operators as one character special
symbols.
/home/me/share/opennars/nal/test5/nal5.0.nal: : 86.441ms/test, -63702.527
kb/test, 2.821 uS/cycle, 10214.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.1.nal: : 157.59ms/test, 25660.281
kb/test, 5.023 uS/cycle, 10457.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.10.nal: : 149.849ms/test,
-41994.766
kb/test, 4.924 uS/cycle, 10145.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.11.nal: : 159.41ms/test, 18223.73
kb/test, 5.184 uS/cycle, 10251.0 cycles/test

/home/me/share/opennars/nal/test5/nal5.12.nal: : 95.187ms/test, 14318.875
kb/test, 3.146 uS/cycle, 10086.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.13.nal: : 121.945ms/test,
-47387.438
kb/test, 4.013 uS/cycle, 10129.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.14.nal: : 102.851ms/test,
17528.281
kb/test, 3.402 uS/cycle, 10078.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.15.nal: : 85.258ms/test, 12519.77
kb/test, 2.74 uS/cycle, 10372.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.16.nal: : 127.144ms/test,
22929.312
kb/test, 4.038 uS/cycle, 10496.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.17.nal: : 114.883ms/test,
-37550.234
kb/test, 3.698 uS/cycle, 10356.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.1.nal: : 95.872ms/test,
10450.812
kb/test, 3.026 uS/cycle, 10560.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.2.nal: : 87.685ms/test,
12773.215
kb/test, 2.906 uS/cycle, 10058.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.3.nal: : 100.188ms/test,
9290.609
kb/test, 3.219 uS/cycle, 10375.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.4.nal: : 105.504ms/test,
17930.738 kb/test, 3.403 uS/cycle, 10335.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.18.nal: : 134.105ms/test,
19051.367
kb/test, 4.238 uS/cycle, 10547.0 cycles/test
/home/me/share/opennars/nal/test5/depr/nal5.19.nal: : 107.836ms/test,
19439.734 kb/test, 3.411 uS/cycle, 10539.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.2.nal: : 128.916ms/test, 24838.094
kb/test, 4.198 uS/cycle, 10236.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.20.nal: : 83.279ms/test, 5196.285
kb/test, 2.694 uS/cycle, 10304.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.21.nal: : 107.98ms/test, 11430.598
kb/test, 3.477 uS/cycle, 10353.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.22.nal: : 71.338ms/test, 7274.375
kb/test, 2.318 uS/cycle, 10257.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.23.nal: : 100.059ms/test,
-34401.922
kb/test, 3.186 uS/cycle, 10467.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.24.nal: : 84.691ms/test, 14046.887
kb/test, 2.722 uS/cycle, 10371.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.1.nal: : 84.936ms/test,
15050.227
kb/test, 2.816 uS/cycle, 10053.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.25.nal: : 84.835ms/test, 14514.5
kb/test, 2.784 uS/cycle, 10157.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.26.nal: : 111.028ms/test,
-32310.324
kb/test, 3.673 uS/cycle, 10077.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.27.nal: : 109.6ms/test, 16771.738
kb/test, 3.519 uS/cycle, 10382.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.28.nal: : 111.241ms/test,
-31039.051
kb/test, 3.542 uS/cycle, 10469.0 cycles/test
/home/me/share/opennars/nal/test5/nal5.29.nal: : 99.578ms/test, 14417.066
kb/test, 3.156 uS/cyc
On Tue, Jun 2, 2015 at 2:21 AM, Jim Northrup<EMAIL_ADDRESS>wrote:

WantsZeroCopy was just a practice run i don't see it bering a feature
that's distinct against prautobeans implicit zero-copy options and lazy
iteration.
what comes next is to convert the class hierarchy
from
[image: image]
<

https://cloud.githubusercontent.com/assets/73514/7929537/131543c8-08b4-11e5-9a19-c2c7b9ac5cbb.png

and to
[image: image]
<

https://cloud.githubusercontent.com/assets/73514/7929527/fc790f8c-08b3-11e5-91d5-ed10a96239c2.png

into a src/main/proto/nars.proto with generator. then the same places
that
were modified for WantsZeroCopy key maniuplation will need to support
the
generated interfaces. semantics should not change, but i have seen at
least
one static singleton map that will provoke a discussion of re-entrant
practices
—
Reply to this email directly or view it on GitHub
<https://github.com/opennars/opennars/issues/37#issuecomment-107824189
.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-107839533.

—
Reply to this email directly or view it on GitHub
https://github.com/opennars/opennars/issues/37#issuecomment-108003328.

regarding off-heap:
1.5.5 branch "at62classes" has a full prautobeans state implementation expressing the fundamental changes required for refactoring.
first: convert all instance methods with stateful objects to static.
second: convert to structs cheaply one at a time using proto in nars_data
regarding boost fusion:
project bbcursive is using variadic template generic systeax toi define signalling tuples from immutable input bytes allowing for polylglot access to memory by default via mmap and other trampoline buffer options.


/tp and /tphere teleport location bug

in the current rocket beta build 470 for <IP_ADDRESS> if u use /tp or /tphere it puts u way under the map in water, when u relog it puts u back on land, but currently it will put u WAY under the map when u use rocket's tp commands

Tested it on another server.  Only happened for me while in god mode.  If god mode is disabled, tp works just fine.

Well thats interesting, the strange things updates can messup never cease to amaze me

Are there any errors in your console by chance?

None that i remember, and i normally keep a close eye on the server console

I added a feature that does detect god mode and teleports you under the world so it would not flicker, probably messed something up here..

Reverted the change, weird..