ERROR: "watch:ts" exited with 1.

Hi @akudev .
Thanks for the tutorial but when I try to run generated project I am getting an error:
Syntax error in file name, folder or ...
ERROR: "watch:ts" exited with 1.
Screenshot attached.

Maybe problem in updated packages version ?
  "devDependencies": {     "@babel/cli": "^7.16.0",     "@babel/core": "^7.16.0",     "@babel/preset-env": "^7.16.4",     "@babel/preset-typescript": "^7.16.0",     "@openui5/ts-types-esm": "1.103.0",     "@types/jquery": "3.5.1",     "@typescript-eslint/eslint-plugin": "^5.6.0",     "@typescript-eslint/parser": "^5.6.0",     "@ui5/cli": "^2.14.1",     "babel-preset-transform-ui5": "^7.0.5",     "eslint": "^8.4.1",     "npm-run-all": "^4.1.5",     "typescript": "^4.5.3",     "ui5-middleware-livereload": "^0.5.8"   },

@karpovas1505 Well, incidentally I just followed the entire tutorial on my own from scratch, as preparation for our UI5con workshop, and I did not face any such issue. I have the exact same dependency versions.
At which step does the error occur? Right in the beginning after the creation from the template (after exercise 1)? Or later, after you already did changes in the application code?
If it happened right after exercise 1 maybe something suspicious pops up when you show us the .yo-rc.json  file (containing the data entered in the generator).
Which node version are you using? (14 over here)
And which easyUI5 version? (npm info generator-easy-ui5 version)

Hi @akudev
It happened right after generation project structure  and when I try start application(npm start)
I don't know whats wrong.
.yo-rc.json - content below
{
"generator-ui5-ts-app": {
"application": "myapp",
"namespace": "com.myorg",
"framework": "OpenUI5",
"frameworkVersion": "1.103.0",
"author": "as.karpov1",
"tstypes": "@openui5/ts-types-esm",
"tstypesVersion": "1.103.0",
"appId": "com.myorg.myapp",
"appURI": "com/myorg/myapp",
"setupCompleted": true
}
}
$ node -v
v16.14.0
$ npm info generator-easy-ui5 version
3.4.0

Hi @karpovas1505
The error message (in English: "Syntax error in file name, folder name, or volume label") does not come from TypeScript or NodeJS, but from the Windows operating system. At least judged by other appearances in the web.
Now what's different on your Windows machine, compared to mine? Two things come to mind: first, you are using MinGW, and second, you are using Cyrillic characters.
The latter wouldn't be suspicious as long as they are not used in path names, but it's notable that several other people who hit the same problem (e.g. here, here, here, here and here) also use Cyrillic characters! That's all the first hits on Google I opened! I doubt this is pure incidence.
But I'm not sure how to proceed from here, as it's not clear what the file/folder name in question is or how to find out.

Hello @akudev
I think the problem in command in package.json
"watch:ts": "babel src --out-dir webapp --source-maps true --extensions ".ts,.js" --copy-files --watch",
".ts,.js" - problem in this part of string. It doesn't work in windows

Resolved by update npm version from 8.13.0  to 8.14.0


Update open.js

This test should not pass on Windows because there are not allowed filenames with quotes, please remove it.

Why don't you simply sniff your os and let windows pass instead of removing it?

Hi Steve,
I need to get this working on Windows too... Unfortunately I didn't have found a way to skip those testings in build phase.
Any suggestions?


All the AI issues I could find

Singulo / tesla can eat the AI's "eye" and brick the player
There is no way to save an unanchored AI.
AI functions without power
AI can see through depowered cameras
AI can sometimes see through cameras with cut wires
AI can see through cameras when the camera router is broken / unwrenched
AI cannot interact with high-security doors
AI can only be "killed" via minibombing its tile and unanchoring it
Doors need an AI control wire

That seems to be the extent of it. Looking into finding a few more

4 is intentional with ss13 parity

I feel like its gotta be a bug on 13 too, cause like. The cameras have no power

#31543

I can see a case both ways for 4.
The AI seeing through de-powered cameras is unrealistic and makes it more of an omnipotence than an AI. However this means that during a power failure of the station (which happens a lot on LRP :P) the player can still play instead of just being literally in the dark.
On the other hand:
The AI not being able to see through powered cameras is more realistic, and it means that there's a consequence for power failure (so the AI might have an incentive to "protect" engi) and it allows antags to actually hide things from the AI by just removing power to a camera.
Note that the "realism" argument is pretty much meaningless since ss14 is more focused on being fun than realistic. So the main comparison here is:

Omnipotent AI that can see in places that are destroyed as long as the camera hasn't been destroyed
OR
Regular AI that has reason to be aware of and care about power failures on the station (which can also benefit the crew since power failures are generally a bad thing for crew)

Would it be possible to those areas to stop updating so AI can "see" the rooms but receive no updates until power is restored?

Would it be possible to those areas to stop updating so AI can "see" the rooms but receive no updates until power is restored?

probably could do that. That's a game design question and also might be challenging or impossible to feasibly implement but I dunno :shrug:

Maybe make cameras have an internal battery like emergency lights that lasts like 15 minutes


OSPF Area

Hi,
Do you know how to create an OSPF Element (Area, Profiles at least) and Add to the routing table on an Interface Vlan.
Regards,
Rémy Pouchain.

The soonest is better ;)
Le 23 mai 2018 12:36:00 GMT+02:00, David LePage<EMAIL_ADDRESS>a écrit :

Hi Remy,
I will add, just finishing up the module so you will be able to add
ospf area and ospf profiles. Will let you know when I can push to
develop branch.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/gabstopper/ansible-stonesoft/issues/19#issuecomment-391301293

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Good good ! Thanks a lot
Le 23 mai 2018 12:36:00 GMT+02:00, David LePage<EMAIL_ADDRESS>a écrit :

Hi Remy,
I will add, just finishing up the module so you will be able to add
ospf area and ospf profiles. Will let you know when I can push to
develop branch.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/gabstopper/ansible-stonesoft/issues/19#issuecomment-391301293

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Hi Remy,
A new version is posted. You will need to grab it from the develop branch. This is the new release staging branch so I can keep the master branch for the primary release. It is getting closer to a more formal release with versioning. You will also need the latest smc-python as well (from master).

Hi Remy, I forgot to point you to an example. Here is a yaml for creating OSPF Area and OSPF Profiles: https://github.com/gabstopper/ansible-stonesoft/blob/develop/playbooks/ospf_element.yml
You can also use the ospf_element_facts.yml the same way as the engine.yaml to retrieve an existing element, change and resubmit (or even just use the facts yaml to check for proper syntax and options, remove the ones you don't need and run).

And how to add to the routing table ?
Le 25 mai 2018 14:12:40 GMT+02:00, David LePage<EMAIL_ADDRESS>a écrit :

Hi Remy, I forgot to point you to an example. Here is a yaml for
creating OSPF Area and OSPF Profiles:
https://github.com/gabstopper/ansible-stonesoft/blob/develop/playbooks/ospf_element.yml
You can also use the ospf_element_facts.yml the same way as the
engine.yaml to retrieve an existing element, change and resubmit (or
even just use the facts yaml to check for proper syntax and options,
remove the ones you don't need and run).
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/gabstopper/ansible-stonesoft/issues/19#issuecomment-392034801

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

You can add like the BGP setting, from the engine yaml:
https://github.com/gabstopper/ansible-stonesoft/blob/develop/playbooks/l3fw.yml
ospf:
  enabled: true
  ospf_areas:
  - interface_id: '2.1'
     name: myarea
     #network: <IP_ADDRESS>/24
     ospf_profile: Default OSPFv2 Profile
     router_id: <IP_ADDRESS>

ospf_areas is a list of areas and interface mappings.

Ok thanks !
Le 25 mai 2018 14:58:46 GMT+02:00, David LePage<EMAIL_ADDRESS>a écrit :

You can add like the BGP setting, from the engine yaml:
https://github.com/gabstopper/ansible-stonesoft/blob/develop/playbooks/l3fw.yml
ospf:
 enabled: true
 ospf_areas:
 - interface_id: '2.1'
    name: myarea
    #network: <IP_ADDRESS>/24
    ospf_profile: Default OSPFv2 Profile
    router_id: <IP_ADDRESS>

ospf_areas is a list of areas and interface mappings.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/gabstopper/ansible-stonesoft/issues/19#issuecomment-392050044

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

The API won't change when I post this but I am adding better reporting when modifications are made so the 'state' attribute returns a simple list of dicts that indicate 'name', 'type', 'action'. So when you make a modification, you can see what was modified without having to double check in the SMC. It will be transparent to the existing functionality.

OSPF elements can be created in commit d83da5b.

How to add add OSPF Area on a Vlan interface ?


Fix x-axis in linearTimeSeries

The linear time series component was appending the x-axis to the container (passed into the component), rather than the mainContainer (created by the component); this resulted in the x-axis being added outside of the chart's SVG:

This pull request appends the x-axis to the appropriate container - mainContainer - (so it can be positioned and sized properly, relative to its parent) and adjusts the plot area and y axis container positioning.

Well spotted - thanks for the fix

Sorry @jleft, I believe this PR should be reverted.

The linear time series component was appending the x-axis to the container (passed into the component), rather than the mainContainer (created by the component); this resulted in the x-axis being added outside of the chart's SVG.

This was intentional. As a general rule, our components should not create container elements. The mainContainer svg element was intended as the first row of a two row flex layout. It is an svg element so that overflow hidden can be set on it rather than using a clipmask. The x-axis should render as the second row and it's labels should overflow as the parent container sees fit.

This pull request appends the x-axis to the appropriate container - mainContainer - (so it can be positioned and sized properly, relative to its parent) and adjusts the plot area and y axis container positioning.

Was there actually a layout problem or is this just an explanation of your changes?

Short answer: sorry for the misunderstanding - that all seems fine, happy to revert :smiley:. An SVG element, to be used as a container, is missing from the multi series visual test and needs to be added.

Longer answer:

This was intentional. As a general rule, our components should not create container elements.

Agreed. I wasn't sure if an exception to the rule might be the fc.chart components - if a component is creating an entire chart, one might want the containing SVG element (which is essential for the chart) to be created too - either way is fine to me.

The mainContainer svg element was intended as the first row of a two row flex layout. It is an svg element so that overflow hidden can be set on it rather than using a clipmask. The x-axis should render as the second row and it's labels should overflow as the parent container sees fit.

Okay, that makes sense - happy to go with this approach and revert.

Was there actually a layout problem or is this just an explanation of your changes?

I observed that the axis in the multi series visual test didn't look right - the domain line and ticks weren't visible and the tick labels weren't positioned correctly:

When I inspected, the structure was:
<div> <!-- container -->
  <svg></svg>
  <g></g> <!-- x-axis container -->
</div>

Initially I thought the x-axis container g was appended to the incorrect container, hence this pull request. However, it just seems the test was missing a containing SVG element.

Cool, I'll stick a new PR in to sort that out and revert these changes.

Cool, I'll stick a new PR in to sort that out and revert these changes.

Thanks, sorry for mix-up! (Also, more than happy to create a PR to sort this out, as I caused this.)

No worries, #381 contains the revert and a little more.


[FIX,PROFILING] Fix gpu timer name and lookup

In the switch from gpu to cuda naming, the cuda timer was passed over. Renaming it to "profiling.timer.cuda" so it is correctly picked up by the timing mechanisms.
@AndrewZhaoLuo

@AndrewZhaoLuo its hard to quantify what sort of improvement you would see.

Wait, so what change will this actually have a on numbers from profiling?
Will there be less overhead, will kernels be more accurately timed, etc?

Yes, this will improve accuracy and decrease overhead.


Allow setting Yandex Translate API key

The Yandex Translate component doesn't have a API key property field. This restricts me from setting my own API key in the component when running the AI server offline. Using the component otherwise yields "Error 2201".
I propose to add a new String property to the Yandex Translate component.
Give an example of how this feature would be used
Users can choose to set their own API key.
Why doesn't the current App Inventor system address this use case?
Currently, the API key is set from the server side (?). There is no way to enter own API key.
Why is this feature beneficial to App Inventor's educational mission?
I have no idea.

@mit-cml/staff Is the Yandex Translate API key set manually by you? I could't find any code that sets the API key in question.

@pavi2410 We have a branding branch that we apply to master before building, and one of the commits sets the key for YandexTranslation.

@pavi2410 @ewpatton It is pretty easy to add a property for the key. I'll take this one...


Logitech wrapper does nothing in the 0.6.1-dev2

like the title says, the Logitech wrapper does nothing for me, I click the patch button, and the loading wheel on the side of the arrow appears like if it was doing something, but then nothing happen, no message saying that it's patch, or that it failed, and when i check the Logitech folder, nothing happen with the LogitechLed.dll files,

I fixed this earlier in the dev branch. The fix will be available in the next dev release or 0.6.1

ok, thanks :)


How to work with areas (and devices)

I would like to get the area of an entity and all entities belonging to one area, but if I have not missed something there is no possibility to do this through pyscript directly.
This functionality would allow to create very universal automations, e.g. a window sensor could turn of all heaters in the same room when the window is opened and turn them back on when the window is closed and all other windows in the same room are closed as well. For this the area_id of entities needs to be accessible and entities need to be selected based on area_id and device type (domain, class).
I found some information in the dev docs of homeassistant and with the hass object I was able to retrieve this info:
import homeassistant
ent_reg = homeassistant.helpers.entity_registry.async_get(hass)
ent=ent_reg.async_get('<entity>')
area = ent_reg.async_get(ent).area_id

Unfortunately this is typically None, if entities inherit the area from their device. Therefore, first the device is needed:
import homeassistant
ent_reg = homeassistant.helpers.entity_registry.async_get(hass)
dev_reg = homeassistant.helpers.device_registry.async_get(hass)
ent=ent_reg.async_get('<entity>')
dev=ent.device_id
area = dev_reg.async_get(dev).area_id

Getting all devices of an area: homeassistant.helpers.device_registry.async_entries_for_area(dev_reg, area)
and from this all entities could be fetched and somehow filtered for domain/class.
That said, I have a couple of questions:

Is this the correct way of doing it or is there a better way? (I am new to pyscipt and have never worked with hass internals before)
could this be integrated into pyscript?
If not I would probably write some helper functions which return the area_id for an entity or return entities based on area/domain/class
Other thoughts?

(#138 might be related)

I don't really use the areas features of Home Assistant. However, the few times I've tried to mess with them, my pyscript code looked very similar to yours, so I think you're doing it correctly.
I think if you can make this work with helper functions, then that's the way to go (and share your module with the community). No reason to bloat the pyscript core if it can be done another way. However, if the functionality is cumbersome or impossible without integration into the pyscript core, it certainly COULD be included. In that case, you should submit a PR.

Thanks for the feedback.
I am now using these three functions to get the area_id of an entity, the area name, and all entities filtered by class or domain for an area_id:
import homeassistant

devreg = homeassistant.helpers.device_registry.async_get(hass)
entreg = homeassistant.helpers.entity_registry.async_get(hass)
areareg = homeassistant.helpers.area_registry.async_get(hass)

def get_area_id(ent):
    ent = entreg.async_get(ent)
    if ent is None:
        return
    if ent.area_id is None:
        if ent.device_id is None:
            return
        dev = devreg.async_get(ent.device_id)
        if dev is None:
            return
        return dev.area_id
    else:
        return ent.area_id

def get_area_name(area_id):
    area = areareg.async_get_area(area_id)
    if area is not None:
        return area.name

def get_entities_for_area(area_id, domain=None, device_class=None):
    entities=homeassistant.helpers.entity_registry.async_entries_for_area(entreg, area_id)
    entities.extend([e for x in homeassistant.helpers.device_registry.async_entries_for_area(devreg, area_id) for e in homeassistant.helpers.entity_registry.async_entries_for_device(entreg, x.id)])
    if domain is not None:
        entities=[e for e in entities if e.domain==domain]
    if device_class is not None:
        entities=[e for e in entities if e.device_class==device_class]
    if entities==[]:
        return []
    else:
        return [e.entity_id for e in (entities or [])]

(Some lines of code are only needed because of #236)
For me this is working fine. Only drawback is that the hass object is needed.

This is short, clean code!
Since these functions are not using any of the pyscript language features, you could decorate them with @pyscript_compile which should make the list comprehensions work the way you expect them to again.
If these were included in the core, they would still have to use the hass object. It would just mean the user wouldn't have to enable the hass object in their config since this is always available in the core. But, as a test, I just stuck these into modules/area_helpers.p, included the @pyscript_compile decorators and then wrote a test script:
import area_helpers

area_id = area_helpers.get_area_id('switch.bathguest_exhaust')
log.info(f'AREA ID: {area_id}')

area_name = area_helpers.get_area_name(area_id)
log.info(f'AREA NAME: {area_name}')

area_entities = area_helpers.get_entities_for_area(area_id)
log.info(f'AREA ENTITIES: {area_entities}')

It works perfectly! So this is very usable even without being in the core and would be a great contribution to the community for anyone wanting to work with areas.

Thanks, that is exactly how I am using it.
@pyscript_compile is a very good idea, makes get_entities_for_area cleaner:
@pyscript_compile
def get_entities_for_area(area_id, domain=None, device_class=None):
    entities=homeassistant.helpers.entity_registry.async_entries_for_area(entreg, area_id)
    entities.extend([e for x in homeassistant.helpers.device_registry.async_entries_for_area(devreg, area_id) for e in homeassistant.helpers.entity_registry.async_entries_for_device(entreg, x.id)])
    if domain is not None:
        entities=[e for e in entities if e.domain==domain]
    if device_class is not None:
        entities=[e for e in entities if e.device_class==device_class]
    return [e.entity_id for e in entities]

get_area_id_by_name is very simple:
@pyscript_compile
def get_area_id_by_name(area_name):
    area = areareg.async_get_area_by_name(area_name)
    if area is not None:
        return area.id

So, should I add this somewhere else, docu/wiki/etc, to increase the visibility for the community?

I would upload the code to a github repo and then mention it in the wiki. That way people can find it if they need it.

I found a much easier way to do this that I had to share.
All of the information requested is available as template filters.  If we import the template module, we have access to all of the same data and features that we have when using Jinja templates.
Just add this import:
import homeassistant.helpers.template as template

and you can make calls like this - note that you just need to pass in the hass object when using in Pyscript
area_entities = template.area_entities(hass, "kitchen")

or
device_id = template.device_id(hass, "light.kitchen_sink")
device_entities = template.device_entities(hass, device_id)

you can even play with Template State objects if you wanted...
state_attributes = template.TemplateStateFromEntityId(hass, "light.kitchen_sink").attributes

@MizterB you have just opened a pandora's box for me. Thank you!

I think there were some good solutions proposed, so I will close here. Thanks everyone


Uniquely identify client connections from dumpfiles.

I'm currently running an issue where I read a saved flow file and I need to match flows to HTTP connections.
The intuitive way to do this would be to compare f.client_conn == f2.client_conn, which holds true for live connections but not for saved ones, because each flow has its own distinct ClientConnection object. Possible ways to fix this:

Add __eq__ implementation to ClientConnection (either by checking ip tuples + timestamp or by adding a unique id)
Enhance FlowReader to re-use ClientConnections. I don't like this, but that would be more consistent with the live behavior.
???

The same problem applies to ServerConnections.
@mitmproxy/devs: thoughts?

Thinking more about this, option 2 would not work without significant changes to how we save flows. Given that connections should be read-only anyway, let's go for implementing __hash__ and __eq__.

A definite +1 for a persistent ID to identify connections, rather than object identity.

A persistent ID is analogous to what we do with flows, and leaves us open to vary the attributes of the object without confusion. I think eq and hash could still rely on the persistent ID. This is a somewhat fine distinction: my main point was not to use object identity - that is, re-use ClientConnection objects as I understood your second option.

Ok, let's do that.

As an addendum, I'd probably prefer not to implement hash, here. When we need to handle ClientConnection objects, I'd probably rather have an explicit d[conn.id] = conn.


⚠ ClamAV has degraded performance

In d7cdd55, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 459 ms

Resolved: ClamAV performance has improved in 8786363.


Apriori algorithm is inefficient. Would you consider writing FP-Growth algorithm and Eclat algorithm?

Apriori Features: you need to scan the database many times, which is inefficient for large scale data.
FP-Growth Features: two scan database, divide and conquer strategy to effectively reduce search overhead.
Eclat Features: it only needs to scan the database one time. If TID collection is very long, it will cost a lot of memory and computation time.
I'm not good at English. I have a brief summary of it.

If I want to write a probability analysis of millions of lottery tickets in Europe, what is the appropriate algorithm?
The method is to collect all the previous numbers and calculate the probability of the next number.


Turn off TLSv1 in Traffic Portal

What does this PR (Pull Request) do?
It turns off TLSv1 in Traffic Portal
Which Traffic Control components are affected by this PR?

Traffic Portal

What is the best way to verify this PR?
docker run -it drwetter/testssl.sh:latest -p <server>
If this is a bug fix, what versions of Traffic Control are affected?
Not a bug fix.
The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[ ] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[ ] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4827/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4828/


support esnext module format for tree-shaking purposes

It would be great if sanctuary could introduce a esnext version to support tree-shaking and a more modular approach.

I'm aware that this is possible, but I don't know any of the details. Can you recommend a resource for learning about this, @mrtnbroder?

If you want, I could give this a shot myself. It's actually not that 'hard' to do, just tedious. But the effort is worth it.
Actually, it's just looking at the modularity of your project and splitting parts of them into their own file/section, so one could import maybe from 'sanctuary/lib/maybe directly as an example.
It's a bit cumbersome to do this in es5 syntax, so I'd probably go the way of adding babel and a little prepublish script that produces an esnext and an es5 version of this lib.
if you want to learn about the module format in general I can recommend this section of "Understanding ES6" https://leanpub.com/understandinges6/read#leanpub-auto-encapsulating-code-with-modules

Take a look at https://github.com/reactjs/react-router for a pretty good example of how this can be done, @davidchambers !

@mrtnbroder I may well be wrong on this, but is it true that
a) It's as easy to split the file up and do require('sanctuary/maybe') in commonJS
and b) It's not necessary to split the file up to get the benefits of tree-shaking, but rather the move to the static exports of ES6 is what does the work?
My understanding is that splitting into files and doing the require('sanctuary/maybe') allows people to pick 'by hand' any code they wish to bundle and the exports allow automated tools to figure out what code you are using

I do :heart: the lack of any build step in this project, but I do appreciate the advantage this change would provide.

If you want, I could give this a shot myself.

I'd love to see a proof of concept. Perhaps you could put together a patch to show this working for a handful of functions.
This is all new to me, @rjmk, but I'm very interested to know whether your understanding is correct.

@davidchambers I'd like to echo your sentiments on the lack of build step

It's not necessary to split the file up to get the benefits of tree-shaking

Correct. It just requires the export syntax.
@davidchambers whats wrong with a build step? It doesn't necessarily require a build tool like gulp or something. Babel would be enough to compile to ES5. It's a one-liner in the package.json file.
Alright then, let me see if I can provide a simple patch. Will take a bit though, I am a bit busy atm ;)

whats wrong with a build step?

One can make things reasonably pleasant. Let's say one's using Make. One can have make test run make to ensure that one's tests always run against the latest build.  One may then wish to run
$ node_modules/.bin/mocha -- test/someFunction.js

to test a specific change. One may be surprised that the tests are still failing. Oh, we forgot to include make && at the start of the command!
Another issue is that Make relies on file modification dates, which is sometimes problematic when changing branches. So sometimes one finds oneself needing to run
$ rm -r dist && make && node_modules/.bin/mocha -- test/someFunction.js

to ensure that the JavaScript file one is testing is up to date.
These problems are minor, but losing five or ten minutes figuring out why changes are not taking effect does negatively affect my attitude towards a project.
Another source of complexity is how to handle the generated files. One problem I encountered with CoffeeScript projects was that contributors would sometimes include changes to the generated file in their patches, even if the generated file was intended to be updated only at release time. This can be avoided via careful use of git update-index, but this adds another possible source of confusion: changes to the generated file are not visible when one runs git status.
In Ramda's case, there's another source of complexity caused by the use of a custom build script. We must test both require('ramda').someFunction and require('ramda/src/someFunction'). On at least one occasion an incorrect require path meant requiring a certain function did not work, though the function behaved correctly when imported as part of the 'ramda' module.
None of these problems is insurmountable, but having spent many hours working with JavaScript projects with build steps over the past several years, working on Sanctuary is a breath of fresh air.

usually you add any build output to the .gitignore so people change the source and not the output code. You only get the output code when you npm install the package.

Also, you can just export { all, these, tasty, functions } at the index.js so you can import everything from the index.js file. One should actually never explicitly import a function that was intended to be private to the lib from the source directory, only from the public api.

:+1: this!

I'm on it!

Almost done 😍

I have one major problem with the create function though @davidchambers I'm not sure how to support it now where everything could be imported directly via import { T } from './sanctuary', where T and everything else is already defined by a default def function
One idea that comes into mind is that the checkTypes prop will depend on the NODE_ENV being either production or not. So type checking is there when you are in dev mode, and not when you make a production build.
Another idae would be to add a flag like --check-types so it does check types on runtime, and not if you do not provide this flag.
I think the best idea would be though to completely get rid of the S.create function and let people define their newtypes within a separate file, and do not pollute sanctuary with their stuff. It doesn't make a lot of sense to me either way. One should not extend jQuery for example with their own functions 'just like that', but rather write a plugin for it.
I hope it makes sense to you what I mean, I'll push a WIP version in a moment to my fork: https://github.com/mrtnbroder/sanctuary

I think the best idea would be though to completely get rid of the S.create function and let people define their newtypes within a separate file, and do not pollute sanctuary with their stuff.

The require('sanctuary') module is never modified: S.create returns a new Sanctuary module which has access to an environment via its closure. There's no pollution.
Ideally Sanctuary would not require knowledge of one's types, but #188 demonstrates that it does.
Many Sanctuary functions are polymorphic. Take concat :: Semigroup a => a -> a -> a, for example. How is it that we're able to provide the following behaviour?
S.concat('abc', [1, 2, 3]);
// ! TypeError: Type-variable constraint violation
//
//   concat :: Semigroup a => a -> a -> a
//                            ^    ^
//                            1    2
//
//   1)  "abc" :: String
//
//   2)  [1, 2, 3] :: Array Number, Array FiniteNumber, Array NonZeroFiniteNumber, Array Integer, Array ValidNumber
//
//   Since there is no type of which all the above values are members, the type-variable constraint has been violated.

The answer is that each time we encounter a value of type a we refine the possible values (types) of a. In order to do so we need an initial set of types to filter. Were we to restrict ourselves to built-in types, functions such as concat would not work on values of user-defined types. We could include Either and Maybe in the set of types, but concat would still not work on values of types defined in other libraries.
S.create seems necessary if we're to continue to type check applications of polymorphic functions.

If we want tree-shaking and to play nicely with type checking, I think we would have to have an API change.
One could imagine that either (a) all the functions need to have an env passed into them or (b) create also took the set of functions it was to produce (this would be compatible with (a), it would just apply them to the environment)).
Then one would need an internal Sanctuary file, where one would basically
import { _T, _either, ..., create, env } from 'sanctuary'

var myEnv = env.concat(...)

export var { T, either } = create({ env: env, checkTypes: true, functions: { _T, _either, ... } })

One could also imagine other, slightly different APIs. I think a better one would be
import { T, either, ..., create, env } from 'sanctuary'

var myEnv = env.concat(...)

export default create({ env: env, checkTypes: true, functions: { T, either, ... } })

But I don't know how that plays with destructuring import

Why does sanctuary expose sanctuary-def's create anyway? I'm strictly about separating these from sanctuary. You should import { create } from 'sanctuary-def' and not from sanctuary imho.

One could imagine Sanctuary taking in a def defined by the user with sanctuary-def. It could then use that throughout, but it still wouldn't support treeshaking (I think -- it would only be exporting the one monolithic function).
It could export all the functions with them waiting for a def. Then one would presumably do something like
import myDef from 'my-def'
import { map } from 'ramda'
import { T, either } from 'sanctuary'

export default (R.map(f => f(def), { T, either })

This might be a bit annoying when you're using most of Sanctuary, so it could also have a way of importing everything with the default environment. That might be the "Sanctuary" module and this stuff might be sanctuary-functions.
An entirely different approach might be to change sanctuary-def so that the wrapped functions had a method on them envConcat that can expand the environment for a function on a per-function basis

sanctuary-js/sanctuary-def#74 is highly relevant to this discussion.

You should import { create } from 'sanctuary-def' and not from sanctuary imho.

I don't think this would work. Here are two relevant snippets from Sanctuary's source:

var def = $.create(opts);

var I = S.I =
def('I',
    {},
    [a, a],
    function(x) { return x; });

S.I is defined via def, which is turn depends on opts, which specifies an environment. After defining S.I there's currently no way to retroactively "inject" types into its environment, so S.I is only able to operate on values of types in the environment provided to S.create.
I have a feeling there's a good solution out there. @Avaq and @rjmk have put forward several interesting ideas. Perhaps having each function take an environment as its first argument is the answer. One could then do something like this:
const S = R.map(f => f(env), require('sanctuary'));

It would be less pleasant, though, if requiring functions individually:
const head = require('sanctuary/head')(env);
const init = require('sanctuary/init')(env);
const last = require('sanctuary/last')(env);
const tail = require('sanctuary/tail')(env);

I'm not sure whether the above is something we want to support, though. I'm still getting my head around "tree shaking".

That seems very invasive; I'm not against modularisation but this treeshaking stuff seems to spiralling out of control, I'd rather leave things as they are than go with any of the solutions proposed so far.

@svozza I definitely agree treeshaking is not a good enough reason to do this. It seems to me something like this is definitely worth exploring though for composable environments and good dependency management. Creating extension environments with which one can extend the default environment is definitely possible, but it's hard to create functions which depend on a given environment while keeping as easy an install story.

Perhaps having each function take an environment as its first argument is the answer.

I think I prefer taking def to taking the env. That then would stop as direct a dependence on sanctuary-def.

It would be less pleasant, though, if requiring functions individually

The API wouldn't have to be like that for 2 reasons.

I think there's still place for the functions applied to the default environment. If anything, I would keep sanctuary as the coordinating repo/module that comes 'batteries included'
You could have a central index.js file that exports all the functions. Either

// commonJS

module.exports =
  { I: require('./I.js')
  , S: require('./S.js')
  ...
  }

or
// ES6

export I from 'I.js'
export S from 'S.js'

Though in the ES6 case, I'm pretty sure breaking the files up isn't actually necessary.
This index file would be what one received from require('sanctuary')

@mrtnbroder, perhaps you could open a pull request for the changes you have made so far? Don't worry if there are failing tests and whatnot.

@davidchambers will do so asap. Need to refactor the commits a bit.

Sorry about the delay, much work, wow, not much time.
just wanted to inform you that I did not forget about it!

No problem, @mrtnbroder.
With at least two significant pull requests soon to be merged I just want to make sure you don't spend many hours on this only to find yourself with dozens of merge conflicts only a week later.
By the way, I'll be living in Berlin from tomorrow. If you'd like to get together one day to work on this (or anything else) in person, contact me via email or Gitter. :)

I'm still interested in this, but I'd like to keep the source code in a single file.

I haven't yet seen a clear plan presented. I'm open to making changes to reduce the size of production builds, but every approach proposed so far has at least one significant drawback.

I'm curious what the reasons for wanting to keep this in a single file are @davidchambers

@MikaAK, see https://github.com/sanctuary-js/sanctuary/issues/246#issuecomment-240986805 for my reasons for opposing a build step and https://github.com/sanctuary-js/sanctuary/issues/246#issuecomment-244220089 for the difficulties S.create would cause were we to accept the costs of a build step.

@davidchambers Since Sanctuary does not support tree-shaking what about something like https://github.com/megawac/babel-plugin-ramda ?

What I need to see is a concrete proposal, @kaushalyap. ;)

@kaushalyap The problem is just that Sanctuary hasn't been translated to modular JavaScript. It's mostly that Sanctuary only really exports one function: create, which takes options and returns an object containing all Sanctuary functions. Because Sanctuary is one big function, tree shaking is not going to achieve much.

To solve this problem, I think the approach that presents itself would be to rewrite Sanctuary like this:
// custom.js

import {create, TypeVariable} from 'sanctuary-def'

const a = TypeVariable ('a');

export const id = options => create (options) ('id') ({}) ([a, a]) (x => x)

// ...etc...

// index.js

import * as custom from './custom.js'
import defaultEnv from './default-env.js'

const options = {checkTypes: true, env: defaultEnv}

export const env = defaultEnv;

export const id = custom.id (options);

// ...etc...

A user can now import {id} from 'sanctuary', and the tree shaker can shake away everything else. Or a user can import {id} from 'sanctuary/custom.js' and supply a custom configuration. It would however be a lot less convenient for users to supply the same custom options to all Sanctuary functions. To make that easier we could provide an optional alternative file to import from:
// create.js

import * as custom from './custom.js'

export default options => ({
  id: custom.id (options),
  // ...etc...
})

Now a user can choose between the benefit of tree shaking, versus the benefit of not having to repeat themselves.
It's quite a lot of work to achieve all that, however, and we're still not giving users the best of both worlds.

It's quite a lot of work to achieve all that, however, and we're still not giving users the best of both worlds.

I find this the telling point.  Ramda has gone down the more complex build route, after starting with a single file.  It has probably helped the library grow, but I regret it every time I do anything sophisticated with Ramda.
Satisfying both the users who want to run Ramda on Node -- and hence have no problem with many individual files -- and those who run it in the browser and therefore really need a single tree-shaken version is an awful balancing act.

I love Sanctuary's all-in-one-file choice, but I also love Ramda no-dependencies one, and I see little way to end up with both.


Add AlphaStacker exercise that builds more skills for the tree quiz

Requires creating a basic row-building loop and using the counter to insert a space at a given point in the loop.

:+1:


feat: added runtime version support

PR to support: https://github.com/fabric8-launcher/launcher-creator-backend/pull/86 @quintesse

:tada: This PR is included in version 3.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bump identity framework version

$subject

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2071421263

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2071421263
Status: success


v4.0.0-rc.7

Changelog

fully working search engine (no more buggy results)
updated api docs annotations
added full request validation
added data transfer objects for requests
modernized jikan config (e.g. cache ttl): the config is now passed around as an object instead of an array
added typed enums for each enum specified in the api docs
added unit tests
fixed filtering in seasons API endpoints
fixed bugs around top endpoints
fixed top reviews endpoint -- please check the new api docs as the parameters have changed
housekeeping - removed old things
fixed status code inconsistency with upstream MAL server - e.g. if a request is sent to MAL in case of a cache miss, and the response failed from MAL, then the page is not cached and the response code either returned from MAL to the client or transformed to a different one.
request validation errors will now produce a json response with clear error messages
reduced typesense's memory usage: changed the indexing of the data by changing the type of the mal_id attribute to int instead of string, so we can sort by mal_id when looking for items and ordering by mal_id when it's required.
all search endpoints will now properly override search engine options for ordering results in the response
improved roadrunner integration
disabled micro caching for automated tests
fixed an issue with micro caching where the data is asked for multiple times
upgraded dependencies
improved the container images: bumped versions, and added xdebug if you ever want to debug the container
fixed #291
fixed #292
fixed #297
fixed #298
fixed #299
fixed #309
fixed #323
fixed #327
fixed #332
fixed #334
fixed #335

Task list

[x] Add dtos
[x] Refactor controllers
[x] Add unit tests
[x] Refactor existing integration tests to use dummy data
[x] Refactor existing integration tests to avoid calls to MAL during tests
[x] Add documentation about changes, how the class structure have changed
[x] Add documentation about laravel app container lifecycles when using PSR-7 workers and roadrunner application server

New dependencies

https://spatie.be/docs/laravel-data/v2/introduction -- used for request validation
https://github.com/spatie/laravel-enum -- used for request validation
haydenpierce/class-finder -- used for model lookups during test runner bootstrap

Architecture changes
This PR changes the core architecture of the app. Instead of having some "query builder" classes which are used throughout the methods of "controller" classes, there is now a mediator pattern in place, where the controller uses a mediator instance to handle the request. This resulted in pairs of a request handler and a strongly typed request object aka data transfer object.

Changes over time (since June, 2022)

Request handlers
These classes are configured in the AppServiceProvider class, which tells the Laravel container how to build these classes.
These are then fed to the singleton mediator instance, which looks them up by their requestClass method.

Trivia: I have a strong C#/ASP.NET background, there you can use generic classes, but in PHP you can only annotate the classes as generic class, and have their type parameter as return value in one of their methods.

Data transfer objects
Thanks to Spatie's laravel-data package, all request validation is done by creating specialisations of their Data class. This also meant that the php version should be greater or equals to 8.1, because the package encourages the usage of attributes/decorators, which was introduced in php 8.1.
Unit of Work and Repositories "pattern"
There is already some sort of "unit of work" pattern in place in Laravel. This new one introduced by the PR, is something similar:
Have a class representation of all possible tables, which are queryable. This will help to have an overview of all the data the app is dealing with.
Repositories are just abstractions over the model classes and they are encapsulating the special queries for those models. There is also a special repository interface implementation which is meant to represent a queryable collection from mongodb. It takes a collection name string as constructor argument.
These two additions will encapsulate the data access in the app. Worth noting here that by data access we mean the "cached" data from upstream.
Consolidated way to do cache lookups
Jikan essentially is a big cache, where some of the models are indexed and searchable. If the record in the database is stale, then a fresh version is scraped from upstream. There is now a "service" in the code which does the cache validation and the cache update: CachedScraperService.
This service uses the repositories to lookup data, and if the data is stale, it uses the MalClient class instance from the Jikan lib to fetch a new version from upstream.
More dry code
There are now less repetitions. The core logic of the app are now centralised across a few core classes:

DefaultCachedScraperService class for scraping from upstream if content in DB is stale, otherwise it returns cached content from DB.
RequestHandlerWithScraperCache base class for all those request handlers which are returning not indexed data.
ItemLookupHandler base class for all those request handlers which are returning indexed data by a key. (Id, username etc.)
SearchRequestHandler base class for all those request handlers which allows the clients/users to search indexed data.

RoadRunner quirks
There are some consequences of using roadrunner as application server: The lifecycles of objects are a bit different.
Under RoadRunner the application lives as a PSR-7 worker, there can be many running workers in parallel, where each of them is a dedicated process. These processes are managed by RoadRunner. The application will be loaded and boostrapped only one  time when the Worker process starts up. This means that the whole application can be stored and kept in memory, instead of the usual per request bootstrap and loading into memory procedure. (E.g. apache web server + modfpm / modphp or nginx + fpm) This also means that the instances in the IOC container remain in memory, and they are only unloaded when roadrunner stops, or it reduces the number of workers.
The IOC container is the core concept of Lumen/Laravel's structure. It can be used for application binding, singleton, resolving applications, dependency injections and more. Without RoadRunner and Workers you don't have to care about the usages of global properties, static class, singletons. With RoadRunner now it matters.
For example, auth in Laravel is registered as singleton. Here is the partial code of SessionGuard:
if (! is_null($this->user)) {
    return $this->user;
}

It looks pretty normal and reasonable for caching resolved user object. But in our case, this is a fatal problem. That will cause you getting wrong user object after your first user resolving.
All of this is resolved through the pushrbx/lumen-roadrunner package, which provides a sandbox to prevent some common unexpected bugs.

lumen-roadrunner is a fork of spiral/roadrunner-laravel

Sandbox container
All the requests are processed in a sandbox of App Container. Any changes to Application class instance will not affect the initial Lumen application. Application bindings will also be resolved in every request. That means singleton instances only exist in the current request, and will not interfere with other requests.
However some instances can be marked to be pre-resolved in the beginning of the Worker's loop to prevent any unnecessary repeated resolving. This can be configured in the roadrunner.php configuration while or in the AppServiceProvider class of the app:

services to warm: the list of instances to keep in memory
services to clear: the list of instances to clear out after each request

For example instances handling database connections with pooling  might be worthwhile to keep in memory.

Disclaimer: the above explanation about object lifecycles under RoadRunner is inspired by laravel-swoole 's documentation.

@pushrbx Awesome work! 🤩 This is some serious effort. It's going to take me a bit to absorb these changes as my PHP has gotten a bit rusty. But thank you for leaving a detailed explanation and I've also seen you've left some comments within the code. So that really helps!
Due to the massive refactor, I'm breaking down my review into several parts.

[ ] Code Review (Reviewing file changes via GitHub review). Almost there! I've gone through 400~ files 😅 ETA: 22/2/23
[ ] Set up staging server (I'll be setting it up to test out the endpoints. Will share the access here.) ETA: 24/2/23
[ ] Testing endpoints ETA: 24/2/23
[ ] Reviewing tests and integration testing ETA: 25/2/23
[ ] In-Depth Code Review (I'll be syncing with changes locally and understanding the changes in-depth. This won't be a blocker for this PR) ETA: N/A

I will not be covering Docker at the moment as I don't have experience there so I trust you with that. 😄

most fixme -s are related to:

roadrunner shenanigans
the date time accuracy in mongo, because currently in many places it's done based on string. (not sure jensenngers lib converts them or not) There were a few bugs because of this.

@Wamy-Dev That would be great. Please share any issues you come across here or our discord channel: https://discord.com/channels/460491088004907029/1085070803432919121

Also I've found that the elasticsearch bit of the code is completely borked: The jikanPaginate scout mixin is mostly specific to typesense and doesn't work with elasticsearch. So I think the elasticsearch support should be removed, and just focus on typesense for now. However we should keep it "robust" / "pluggable", so if anyone wants to contribute they could easily add an implementation.

Fixed the stuff we highlighted after testing in staging:

genre filtering
added unapproved filtering
fixed sfw filtering
fixed kids filtering
fixed deprecation warnings as of php 8.1

DateTime ctor can't take null anymore as first param
preg_replace doesn't accept null values as $subject

fixed failed items indexer (the --failed option of indexers) -- it didn't load the correct file making it impossible to retry the indexing
changed the document schema for search indexed anime/manga

added approved field to them
staging will require a reimport into TypeSense

the central filtering system will now process sfw and unapproved filters, so they will be applied implicitly through the filter model scope method.

Accordingly the seasons, schedule, random, and search endpoints need testing again on staging.

@pushrbx LGTM. Wanna do the honors?

Amazing work 👏 So it's done? 😇 When will it be pushed to the live rest api?


Many Tree-sitter parsers are unable to be loaded by neovim.

The parser does not work and an error is visible in :checkhealth.

ERROR: Impossible to load parser for tree-sitter-bash: Failed to load parser: uv_dlsym: /nix/store/8m8lpz90rfhw8im1wqribcm55l5llx15-runtime/etc/parser/tree-sitter-bash.so: undefined symbol: tree_sitter_tree-sitter-bash

Steps To Reproduce
Steps to reproduce the behavior:
programs.neovim.runtime."parser/bash.so" = "${pkgs.tree-sitter.builtGrammars.bash}"/parser";

Expected behavior
The parsers all work.

@Profpatsch: Tree-sitter
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.10.52, NixOS, 21.11pre304626.8ecc61c91a5 (Porcupine)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.14
channels(kevincox): ""
channels(root): "nixos-21.11pre304626.8ecc61c91a5, nixpkgs-21.05pre278688.c0e88185200"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
- tree-sitter
# a list of nixos modules affected by the problem
module:
- programs.neovim

Is that still an issue? on latest nixos-unstable I cannot reproduce it. I'm getting errors for some grammars (ABI mismatch) but not for bash
As I side note, I recommend that you install the grammars this way:
https://nixos.org/manual/nixpkgs/unstable#idm140737316593248

I just checked and this is no longer an issue based on nixos-unstable this morning.
And thanks for that link. I looked for it but don't know how I missed it.


NaiveKernel

Codecov Report

Merging #27 (50f1411) into master (7857585) will increase coverage by 0.35%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
+ Coverage   76.40%   76.76%   +0.35%
==========================================
  Files          13       14       +1
  Lines         284      297      +13
==========================================
+ Hits          217      228      +11
- Misses         67       69       +2

Impacted Files
Coverage Δ

src/Entropies.jl
100.00% <ø> (ø)

src/kerneldensity/NaiveKernel.jl
84.61% <84.61%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7857585...50f1411. Read the comment docs.

IN ChaosTools.jl we have
"""
    kernelprob(X, ε, norm = Euclidean()) → p
Associate each point in `X` (`Dataset` or timesries) with a probability `p` using the
"kernel estimation" (also called "nearest neighbor kernel estimation" and other names):
```math
p_j = \\frac{1}{N}\\sum_{i=1}^N I(||X_i - X_j|| < \\epsilon)

where N is its length and I gives 1 if the argument is true.
Because p is further normalized, it can be used as
an alternative for the genentropy function (using the second method).
"""
function kernelprob(X, ε, norm = Euclidean())
N = length(X)
p = zeros(eltype(X), N)
@inbounds for i in 1:N
p[i] = count(evaluate(norm, X[i], X[j]) < ε for j in 1:N)
end
p ./= sum(p)
return p
end

which doesn't use nearest neighbors. It may be that KDTrees are faster but they have large windup time...

A comparison between both approaches (should work on current master branch):
import Distances: Metric, Euclidean, evaluate
import NearestNeighbors: NNTree, KDTree, inrange
using Entropies

""" Abstract type for different estimation methods of kernel densities """
abstract type KernelEstimationMethod end

"""
    DirectDistance(metric::M = Euclidean()) <: KernelEstimationMethod

Estimate kernel densities by direct evaluation of pairwise distances.
"""
struct DirectDistance{M<:Metric} <: KernelEstimationMethod
    metric::M
    function DirectDistance(metric::M = Euclidean()) where M
        new{M}(metric)
    end
end

"""
    Tree(metric::M = Euclidean()) <: KernelEstimationMethod

Estimate kernel densities by a tree-based method of computing pairwise distances.
"""
struct Tree{M<:Metric} <: KernelEstimationMethod
    metric::M
    function Tree(metric::M = Euclidean()) where M
        new{M}(metric)
    end
end

"""
    NaiveKernel(ϵ::Real) <: ProbabilitiesEstimator

Estimate probabilities/entropy using a kernel density estimation (KDE). This is the "naive kernel" approach
discussed in Prichard and Theiler (1995) [^PrichardTheiler1995].

Probabilities ``P(\\mathbf{x}, \epsilon)`` are assigned to every point ``\\mathbf{x}`` by counting how many other points occupy the space spanned by
a hypersphere of radius `ϵ` around ``\\mathbf{x}`` (and normalized after), according to:

```math
P_i(\\mathbf{x}, \\epsilon) \\approx \\dfrac{1}{N} \\sum_{s \\neq i } K\\left(\\dfrac{||\\mathbf{x}_i - \\mathbf{x}_s ||}{\\epsilon} {\right)
```,

where ``K(z) = 1`` if ``z < 1`` and zero otherwise.

[^PrichardTheiler1995]: Prichard, D., & Theiler, J. (1995). Generalized redundancies for time series analysis. Physica D: Nonlinear Phenomena, 84(3-4), 476-493.
"""
struct NaiveKernel{KM<:KernelEstimationMethod} <: ProbabilitiesEstimator
    ϵ::Real
    method::KM
    function NaiveKernel(ϵ::Real; method::KM = Tree()) where KM
        ϵ > 0 || error("Radius ϵ must be larger than zero, otherwise no radius around the points is defined!")
        new{KM}(ϵ, method)
    end
end

function get_pts_within_radius(pts, est::NaiveKernel{<:Tree})
    tree = KDTree(pts, est.method.metric)

    # Count number of points within radius of ϵ for each point in `pts`
    # There's no need to sort the indices, we just count the number of points within radius ϵ.
    idxs = inrange(tree, pts.data, est.ϵ, false)
    return [length(idx) for idx in idxs] # if we're actually getting the points and normalizing later, no need to do ./ N here
end

function get_pts_within_radius(pts, est::NaiveKernel{<:DirectDistance})
    N = length(pts)
    p = zeros(eltype(pts), N)
    @inbounds for i in 1:N
        p[i] = count(evaluate(est.method.metric, pts[i], pts[j]) < est.ϵ for j in 1:N)
    end

    return p
end

function probabilities(x::Dataset, est::NaiveKernel)
    N = length(x)
    p = get_pts_within_radius(x, est)
    return p ./ sum(p)
end

Then run
pts = Dataset([rand(3) for i = 1:5000])
ϵ = 0.2
metric = Euclidean()
method1 = DirectDistance(metric) # option 1: with direct distance evaluation
method2 = Tree(metric)           # option 2: with trees

probabilities(pts, NaiveKernel(ϵ, method = method1))
probabilities(pts, NaiveKernel(ϵ, method = method2))
using BenchmarkTools
@btime p1 = probabilities($pts, NaiveKernel($ϵ, method = $method1));
@btime p2 = probabilities($pts, NaiveKernel($ϵ, method = $method2));

all(p1 .== p2)
all(p1 .== p2)

this gives me
688.678 ms (25000005 allocations: 381.55 MiB)
  22.691 ms (37746 allocations: 16.75 MiB)
true

So it seems that both approaches are equivalent using the same metric and radius, but the tree approach is an more than an order of magnitude faster both in terms of runtime and memory usage.

This is what you'd have to benchmark:
pts = Dataset([rand(3) for i = 1:5000])
ϵ = 0.2
metric = Euclidean()
method2 = Tree(metric)           # option 2: with trees
probabilities(pts, NaiveKernel(ϵ, method = method2))
ChaosTools.kernelprob(pts, ϵ)

using BenchmarkTools
@btime p1 = kernelprob($pts, $ϵ)
@btime p2 = probabilities($pts, NaiveKernel($ϵ, method = $method2));

which gives as result
84.375 ms (2 allocations: 39.14 KiB)
20.663 ms (37742 allocations: 16.72 MiB)

So yeah, trees are faster.

Trees it is then 🌴 Should ChaosTools.kernelprob continue to exist, or will you use probabilities(x::Vector_or_Dataset, est::NaiveKernel())?

No I'll rewrite it with probabilities once we have a stable version. Unification for the win.

Note to self: the direct method is needed too, when dealing with transfer entropies on complex wavelet coefficients. NearestNeighbors trees don't work with complex numbers, whereas distances between complex numbers can be evaluated like in kernelprob using evaluate(Euclidean(), c1, c2) without trouble.

@Datseris The direct approach in this PR is now type-stable. Hence, it is just as fast and allocates as little memory as your method in ChaosTools.jl. See below for benchmark.
The equivalent of ChaosTools.kernelprob(x, ϵ) is Entropies.probabilities(x, DirectDistance()) (which uses the Euclidean metric as default).
using Entropies, ChaosTools
pts = Dataset([rand(4) for i = 1:5000]);
ϵ = 0.2
est_direct = NaiveKernel(ϵ, DirectDistance())
est_tree = NaiveKernel(ϵ, TreeDistance())

p_tree = probabilities(pts, est_tree)
p_direct = probabilities(pts, est_direct)
p_chaostools = kernelprob(pts, ϵ)

using BenchmarkTools
@btime p_tree = probabilities(pts, est_tree);
@btime p_direct = probabilities(pts, est_direct);
@btime p_chaostools = kernelprob(pts, ϵ);

println(all(p_tree .== p_direct .== p_chaostools))

14.100 ms (26720 allocations: 4.29 MiB)
  136.496 ms (6 allocations: 39.20 KiB)
  134.605 ms (2 allocations: 39.14 KiB)
true

The equivalent of ChaosTools.kernelprob(x, ϵ) is Entropies.probabilities(x, DirectDistance()) (which uses the Euclidean metric as default).

Thank you very much. Then, once you merge this and we tag a new version I can update my ChaosTools.jl PR accordingly!

Actually I will simply use the Tree implementation.
BTW kristian are you using NearestNeighbors.jl or the Neighborhood.jl interface I've made? https://github.com/JuliaNeighbors/Neighborhood.jl
I'm moving DynamicalSystems.jl to Neighborhood.jl little by little. If you don't know about it, the just continue here using NN.jl and I'll then come later and move everything to Neighborhood.jl

BTW kristian are you using NearestNeighbors.jl or the Neighborhood.jl interface I've made? https://github.com/JuliaNeighbors/Neighborhood.jl
I'm moving DynamicalSystems.jl to Neighborhood.jl little by little. If you don't know about it, the just continue here using NN.jl and I'll then come later and move everything to Neighborhood.jl

Here, I'm just using NearestNeighbors.jl directly. We can do a switch later on. For now, I prefer to just have a kernel method working, so I can finish porting the relevant CausalityTools.jl method before we tag 1.0.

As far as I can tell this is good to go right? I'll make the transition to neighborhood.jl prior to 1.0.

As far as I can tell this is good to go right? I'll make the transition to neighborhood.jl prior to 1.0.

Yes, the docs also look good locally, so it is good to go. I'll merge and tag

Hm, so I'm updating ChaosTools.jl and I realize that we do have a downside here. Specifically:
kernelprob(X, ε, metric) is deprecated in favor of  probabilities(X, NaiveKernel(ϵ, TreeDistance(metric)))
notice how the latter is massively more verbose...? Should we start adding shorthand names? Or should I simply keep the name kernelprob in ChaosTools.jl and simply make it call the new function?

@Datseris Entropies.jl is just meant as a "library" of entropy estimation methods, and the only "syntax goal" of the package is to export one function to estimate probabilities, and one to estimate entropies. Because there are a lot of different methods, and we dispatch on method types, the syntax for calling a particular method will necessarily be verbose. However, that doesn't need to be reflected in your higher-level package that actually uses Entropies.jl.
I'd argue to just keep the syntax you already have in ChaosTools and call the new function, i.e.
import Entropies: probabilities
kernelprob(X, ε, metric) = probabilities(X, NaiveKernel(ε, TreeDistance(metric)))

I'm rewriting CausalityTools.jl too using Entropies.jl now. For some methods, the syntax will be precisely the same as in Entropies.jl, but not for all methods. My goal in CausalityTools.jl is internally consistent syntax within that package, not necessarily to be consistent with the syntax of some library package from which I import stuff (although its nice to be consistent with Entropies.jl too, where possible).
If we were to introduce shorthand names for some methods, we should do it for all methods. Then the point of having genentropy and probabilities kind of disappears - having a consistent interface.
What do you think?

I'm fine with that, but then how does this align with all the transfer-entropy related methods that are added in PR #31 ? Let's continue in #31 , I'm fine to define kernelprob in ChaosTools.jl.

@kahaaga I've started doing a version of correlationsum based on this approach. Turns out, for many real world scenarios the direct method is much faster.
E.g.:
using Entropies, ChaosTools
ds = Systems.lorenz96(4)
pts = trajectory(ds, 10_000; Ttr = 100, dt = 1.0)
e = 1.2
est_direct = NaiveKernel(e, DirectDistance())
est_tree = NaiveKernel(e, TreeDistance())

p_tree = probabilities(pts, est_tree)
p_direct = probabilities(pts, est_direct)

using BenchmarkTools
@time p_tree = probabilities(pts, est_tree);
@time p_direct = probabilities(pts, est_direct);

3.151221 seconds (140.03 k allocations: 2.448 GiB, 37.56% gc time)
  0.661377 seconds (8 allocations: 156.594 KiB)


PopupMenu item_pressed is sent before checking hide flags.

Sending it afterwards made the checkable items not respond for persistent popups, and borked several editor menus.

This was last moved in #20982, CC @hpvb.

Ah, OK that makes sense. It seemed like such an elegant solution. :) The issue with checking it after is that it causes a crash if you remove items in a signal. I'll have another look at it.

Cherry-picked for 3.0.7.

Actually undid cherry-pick, as #21090 was the final good version.


Fix rootCamera assumption that it knows about all inputs

I think we need to add this to content/scripts/PlayerScripts/StarterPlayerScripts as well


Burrow 1.0 Rewrite

This is a marker issue so that everyone is aware that I'm in the middle of refactoring the structure of Burrow for a major release. Some of the things that are going into this:

Making the app easier to wrap inside another app if desired
Adding support for topic deletion
Updating dependencies and switching to structured logging
Cleaning up the modules for ingesting cluster and consumer data, storage, and evaluation
Make it much easier to extend burrow, including adding new notifiers, storage systems, consumer types, and even clusters.
Adding tests and reducing the complexity of the code to make this easier
Making burrow able to run in parallel and share load, rather than running active-standby
Getting more people at LinkedIn involved in the project

I'm also going to review the issues currently here and flag ones that I'll be working on. I'll be doing the same with the PRs. Unfortunately, this will invalidate all the existing PRs, as the code will be so different that they just won't apply. I'll do my best to pull in the contributions that address issues and features as I do this.
Currently, the work is happening under my fork at https://github.com/toddpalino/Burrow/tree/burrow-1.0. The basic structure of the application is in place, and I'll be working over the next week to move the module code in place

awesome Todd! Looking forward to this re-write and helping out to test it. Especially the "Making burrow able to run in parallel and share load" part.
Are you planning on sticking with Sarama or to the Confluent Go Wrapper around librdkafka?

@toddpalino wow. great news! Thanks for all your hard work

@jiminoc, we'll be sticking with Sarama for now. I'm not a huge fan of wrapper libraries, and Shopify has been doing a good job. Plus we've got more in-house experience with it now, and people willing to help make it better when needed.
However, if someone wants to write a consumer module that uses a different client underneath, that will be entirely possible and much easier to do once this gets done.

makes sense and works for me!
I've always wondered since you can only run 1 burrow right now and you guys have massive installs of Kafka. What kind of hardware are you running burrow on and have you hit any scaling limits with the single node approach? Also, how many burrows are you guys running in production? 1 per cluster or do you have 1 mono-burrow to monitor all the things?

btw, something that burned us in the past is having burrow start at the latest offset. Imagine the situation (which happens) where you have an outage, things go into an ERR state, burrow gets restarted and comes back up. It will lose all of the consumers in ERR state it was tracking because they won't be submitting offsets back. Starting from earliest, while potentially taking longer on bootup, will give better accuracy in tracking status.

@jiminoc - we run 2 burrows per "datacenter", with the built-in active/passive model (where one of them is not notifying). Each one of those pairs cover anywhere from 7 to 20 Kafka clusters right now with varying load levels. We're not using huge hardware for this - our slice sizing for Burrow right now is 6GB of memory and 4 CPUs (and most of them go nowhere near that limit)
I don't like the active/passive model for reasons other than scaling, of course. However, in a system like this it's really hard to operate as a true cluster without having a shared data storage system. Since the current model is just an in-memory map (and I'm going to keep that in the initial 1.0 model), there's no real way around it even if you do run active-active. When a burrow in the cluster fails, another one has to re-learn the consumers from there.
I hear you on the start from latest. I already made a change locally in the last couple months to bootstrap the offsets topic instead, and it really doesn't take that long. That'll be a configuration in the new consumer model, with the default being to bootstrap.

Checkin on the 1.0 progress:
https://github.com/toddpalino/Burrow/tree/burrow-1.0 currently contains the app basics, as well as initial code for the storage and evaluation modules. There's a couple features (like group whitelists) missing from the storage module right now that I'm about to add. But other than that, both the storage and the evaluator modules work, and work together. The next steps will be adding the modules to get both broker and consumer offsets from Kafka (and Zookeeper).
One thing I'm very happy about is that the evaluator now has tests, including a section for passing a set of offsets for a partition and testing all the evaluation routines separately. This means that it's trivial to add a case and test that it evaluates in exactly the way it's expected to. This, combined with the fact that the evaluator logic is a LOT easier to comprehend, will make it much easier to bugfix and prove the correctness of the system.

Hi @toddpalino - when can we expect a 1.0 RC for testing?

Dennis

👋 happy to help testing the rewrite too.

Work continues apace. Had to slow down a little the past week due to oncall concerns, but the cluster, consumer, and notifiers are all done. The remaining module to write is the HTTP server, and then moving up to the top level to make sure the logic that stitches it all together still works.
@daodennis @sam-obeid - I'm hoping to have something that's testable in about another week. At that point I'll move it over to a branch on this repository (instead of my personal one).

Getting closer to something for testing. I've started running the new code in a local environment today and so far I've got it consuming from Kafka again, storing, and evaluating. The HTTP interface also works (which is how I know, as I'm not running any notifiers yet).
I'm in the process of fixing a few bugs here and there, and tweaking some of the operation to clean up what I'm seeing. I expected to be pushing a branch for others to start testing by the end of the week.

OK, the RC branch is there now:
https://github.com/linkedin/Burrow/tree/burrow-1.0-RC
I've been running this version against a cluster internally, and it looks good. I haven't started testing the notifiers yet, however. There is a bit of change to configs, so ask if you need help generating a config file (it's now using Viper, so it's flexible with regards to format).

The RC branch is looking good. I've been fixing a number of issues as I run it in my test environment. I think we're just about ready to take this out of testing and get a little more experience on it internally. Once we've got it successfully running in our test environment for a week or so, I can work on promoting the RC to a full release.
I'll be working on documentation over the next week, including full documentation of the new config format. The application is still lacking metrics, but that can be added on later if needed.

First pass godocs are up. Next step is to document the configuration on the wiki, as well as clean up a copy of the HTTP and notifier docs there.

Alright, the RC is promoted to master now, so I'm closing this out. There are going to be a number of bugs that come up, I'm sure, so I'm not cutting the release just yet.


Providing missing accessor to EVP_PKEY.engine

The accessor to the engine field of EVP_PKEY structure was missing on making internal structures opaque. This patch is designed to provide it.

I rebased this and pushed to master only. I can't backport this to 1.1.1 because the libcrypto.num file references 3_0_0, so a new PR would be required for 1.1.1. @beldmit - can you do that?


Refactoring the multirange decoder

Codecov Report

Merging #15 (9859c87) into master (509353e) will increase coverage by 0.26%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master      #15      +/-   ##
==========================================
+ Coverage   98.36%   98.63%   +0.26%
==========================================
  Files          23       23
  Lines         736      733       -3
==========================================
- Hits          724      723       -1
+ Misses         12       10       -2

Flag
Coverage Δ

unittests
98.63% <ø> (+0.26%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/multirange.c
100.00% <ø> (+5.88%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Input type "date" not working in IE11

The date picker in input type "date" not appearing in IE11.
The behavior is like a normal input type "text"

Unfortunately that's a limitation of IE11. We are styling the HTML5 element, but IE11 doesn't provide it: https://caniuse.com/#feat=input-datetime .
I believe there are polyfills for IE11 that replicate that behavior, and there are also several third-party date selection widgets. Hope that helps...

Oh, ok... well, I will see what I can do about this.
Thanks a lot for your feedback!


Fixed issues from telemetry

Fix syntax error when invalid VAR names are generated for table names containing invalid characters (e.g. space)
Excluded ColumnType.RowNumber from preview
Escape double quotes in FormatString
Fixed issue where commas can be commented out and generate a syntax error if the table expression ends with a comment

This is to avoid the comma being part of the comment if the table expression ends with a comment
VAR __PREVIEW__CalculatedTable =
SELECTCOLUMNS (
    UNION ('MyCalendarTable2020', 'MyCalendarTable2021') -- my table expression comment,  <<-- syntax error because the table expression ends with a comment
    "'__PREVIEW__CalculatedTable'[Date]", [Date],
    "'__PREVIEW__CalculatedTable'[Year]", [Year]
)

VAR __PREVIEW__CalculatedTable =
SELECTCOLUMNS (
    UNION ('MyCalendarTable2020', 'MyCalendarTable2021') -- my table expression comment
    ,
    "'__PREVIEW__CalculatedTable'[Date]", [Date],
    "'__PREVIEW__CalculatedTable'[Year]", [Year]
)


@angular/cli - eject command - testing does not output any coverage reports

Bug Report or Feature Request (mark with an x)
- [x] bug report
- [ ] feature request

Versions
@angular/cli: 1.0.0-rc.4 (e)
node: 6.10.0
os: darwin x64
@angular/common: 2.4.10
@angular/compiler: 2.4.10
@angular/core: 2.4.10
@angular/forms: 2.4.10
@angular/http: 2.4.10
@angular/platform-browser: 2.4.10
@angular/platform-browser-dynamic: 2.4.10
@angular/router: 3.4.10
@angular/cli: 1.0.0-rc.4
@angular/compiler-cli: 2.4.10

Repro steps.
ng new testerino
cd testerino
ng eject -aot -prod
npm test

The log given by the failure.
No failure, but there is no coverage numbers outputted.
Desired functionality.
A coverage folder is created and coverage reports populated.
Mention any other details that might be useful.
The ejected reporters in the karma.conf.js are:
reporters: config.angularCli && config.angularCli.codeCoverage
              ? ['progress', 'coverage-istanbul']
              : ['progress', 'kjhtml'],

I even updated these to reporters: ['progress', 'coverage-istanbul', 'kjhtml'] and still have the same results (as per https://github.com/angular/angular-cli/pull/5514).
Has anyone else ran across this?

SOLVED! Here is what you have to do when you eject the config and get want to get code-coverage. Apologies if this is documented somewhere. Let me know if its not and I can document it.
In your karma.conf.js you have to add:
 angularCli: {
   environment: 'dev',
   codeCoverage: true
 }

The codeCoverage: true is what tells the @angular/cli/plugins/karma to use the post loaders for instanbul. Now, I am able to get proper coverage using the fix from https://github.com/angular/angular-cli/pull/5514 as well.

Thanks for your input @jgodi Setting up the 'codeCoverage' property actually does make the reporter work in a project where ng eject has been applied.
But it only works if we still use the angular-cli in the list of karma framework.
I need to use a different framework with the ejected webpack config. Essentially removing all relationships with angular-cli from the karma config But still using the same webpack.
There is definitely some config that I am missing in the webpack to make the reporter work. Anyone has some clues?

Found out the extra configuration that was missing by going to the angular-cli source code: https://github.com/angular/angular-cli/blob/1cd0a0811df2b7a45cbffb413dd56e3ac21a96e4/packages/%40angular/cli/models/webpack-configs/test.ts
Needed to add this configuration in the webpack to make code-coverage to work with zero dependence on angular-cli
      {         test: /\.(js|ts)$/,          loader: 'istanbul-instrumenter-loader',         enforce: 'post',         query: {           esModules: true         },         exclude: [           /\.(e2e|spec)\.ts$/,           /node_modules/         ]       }

@dreamerkumar any insight into where you added this in the webpack.config.js?

@hikumealan it would be in the module.rules array.
module.rules[
// other rules probably already exist
{
test: /.(js|ts)$/, loader: 'istanbul-instrumenter-loader',
enforce: 'post',
exclude: [
/.(e2e|spec).ts$/,
/node_modules/
]
}
]```


Unknown expense receipt appears after scanning a receipt

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @justinpersaud
Slack conversation: https://expensify.slack.com/archives/C05LX9D6E07/p1729808057159929
Action Performed:

Go to a workspace
Submit an expense
Scan a receipt and  submit

Expected Result:
Only the expense of the receipt scanned appears
Actual Result:
Some unknown expense receipt also appears
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[x] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence
[onyx-state 2.txt](https://github.com/user-attachments/files/17527889/onyx-state.2.txt)

View all open jobs on GitHub

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

Failed to open report<PHONE_NUMBER>199357 Expensify\Libs\Error\ExpError - 4159113a-3199-11ee-be56-0242ac120002 ~~ exceptionJsonCode: '666' exceptionUserMessage: 'No report actions returned in Auth response' exceptionMessage: 'No report actions returned in Auth response' exceptionFile: '/git/releases/expensify.com/d6c337b/lib/ReportAPI.php' exceptionLine: '6324' exceptionCode: '666'

@techievivek any ideas why Justin got this auth error?

@tgolen I think this is another good one for an Internal Hot Pick

I checked the logs https://www.expensify.com/_devportal/tools/logSearch/#query=request_id:("8d7d54870d8936ad-YYZ")+AND+timestamp:[2024-10-24T21:16:15.275Z+TO+2024-10-24T23:16:15.275Z]&index=logs_expensify-030873, and it seems like we are not returning any reportActions for this reportID from the Auth.

We will probably need to run some CQs to understand what's going on here. I am going to create an internal GH and look into it.

Requested for some info in the GH above.

We can received the data ran as part of CQ, I will look into it by tomorrow.

Removing Hot Pick as Vivek has this one

@techievivek have you looked into this yet?

Aaah, sorry, I missed this last week. I can prioritise it this week. Thanks.

Sorry for the lack of an update here. Hubspot integration is taking most of my time. I will take a look into it soon.

Not overdue

I would vote to close this out. Based on the CQ result (https://github.com/Expensify/Expensify/issues/442130), it seems the reportActionID we were expecting updates for doesn’t exist in the database. However, the report itself and other reportActions do exist.


dacapo-avrora_0 fails for JDK 21

This test fails for all platforms:
https://trss.adoptium.net/testPerPlatform?testId=64f69b2117052c6715144c90
It may be due to the use of java.lang.Compiler which is removed in JDK 21. Upstream dacapo has a patch file recently added to fix this https://github.com/dacapobench/dacapobench/pull/219
I have no idea how Dacapo releases are being maintained at the moment. The sourceforge files for 9.12-MR1 referenced via the Dacapo website were from 2018: https://sourceforge.net/projects/dacapobench/files/
Is the Dacapo being run at Adoptium a build from source?
Relevant logs:
2023-09-04T21:46:58.032Z] ===== DaCapo 9.12-MR1 avrora starting =====
[2023-09-04T21:46:58.032Z] Digest validation failed for stderr.log, expecting 0xda39a3ee5e6b4b0d3255bfef95601890afd80709 found 0x06c8c88a2527a461348b8f44257bfb563f20ca1f
[2023-09-04T21:46:58.032Z] ===== DaCapo 9.12-MR1 avrora FAILED =====
[2023-09-04T21:46:58.032Z] Validation FAILED for avrora default

stdout.log:

Avrora [Beta 1.7.110] - (c) 2003-2007 UCLA Compilers Group

Loading /home/jenkins/workspace/Test_openjdk21_hs_extended.perf_x86-64_linux/aqa-tests/TKG/output_16938638279253/dacapo-avrora_0/./scratch/test/tinyos/CntToRfm.elf...OK
Loading /home/jenkins/workspace/Test_openjdk21_hs_extended.perf_x86-64_linux/aqa-tests/TKG/output_16938638279253/dacapo-avrora_0/./scratch/test/tinyos/RfmToLeds.elf...OK
=={ Simulation events }=======================================================
Node          Time   Event
------------------------------------------------------------------------------
Simulation terminated with unexpected exception: ==============================================================================
Simulated time: 0 cycles

The tarball of test results [1] doesn't seem to have the stderr.log file; it would be nice to read that to see what was inside.
[1] https://ci.adoptium.net/job/Test_openjdk21_hs_extended.perf_x86-64_linux/19/artifact/benchmark_test_output.tar.gz
Test Info
Test Name: dacapo-avrora_0
Test Duration: 228 ms
Machine: test-equinix_esxi-ubuntu2204-x64-2
TRSS link for the test output: https://trss.adoptium.net/output/test?id=64f69b2117052c6715144c90
Build Info
Build Name: Test_openjdk21_hs_extended.perf_x86-64_linux
Jenkins Build start time: Sep 04 2023, 05:36 pm
Jenkins Build URL: https://ci.adoptium.net/job/Test_openjdk21_hs_extended.perf_x86-64_linux/19/
TRSS link for the build: https://trss.adoptium.net/allTestsInfo?buildId=64f699f517052c6715144236
Java Version
openjdk version "21-beta" 2023-09-19
OpenJDK Runtime Environment Temurin-21+35-202309042127 (build 21-beta+35-ea)
OpenJDK 64-Bit Server VM Temurin-21+35-202309042127 (build 21-beta+35-ea, mixed mode, sharing)
This test has been failed 3 times since Jul 08 2023, 07:45 pm
Java Version when the issue first seen
openjdk version "21-beta" 2023-09-19
OpenJDK Runtime Environment Temurin-21+30-202307082331 (build 21-beta+30-202307082331)
OpenJDK 64-Bit Server VM Temurin-21+30-202307082331 (build 21-beta+30-202307082331, mixed mode, sharing)
Jenkins Build URL: https://ci.adoptium.net/job/Test_openjdk21_hs_extended.perf_x86-64_linux/17/
The test failed on machine test-equinix_esxi-ubuntu2204-x64-2 2 times
The test failed on machine test-equinix_esxi-ubuntu2204-x64-1 1 times

auto exclude test dacapo-avrora ver=21+

Created the exclude PR https://github.com/adoptium/aqa-tests/pull/4749 until this is resolved.
A source code release was created yesterday: https://github.com/dacapobench/dacapobench/releases/tag/v9.12-MR1-bach
We have a few options:

Wait for a binary release to be available via sourceforge (no work for us, but also unknown amount of waiting)
Switch to build from source from a tagged source code release (some work for us, is a more deterministic approach, though not a 'high priority' item)

Dacapo project now has a 23.11-chopin release here: https://github.com/dacapobench/dacapobench/releases/tag/v23.11-chopin
We can try using it instead of 9.12-MR1

See https://github.com/adoptium/aqa-tests/issues/4858


QueryBuilder forces refresh() if select() was used

Fixes #895
I have tried detecting that document managed by UoW contains less data than just fetched $data in UnitOfWork::getOrCreateDocument but it was ~0.4s slower (for whole test suite) so imo it's no way to go.

This was old and bad idea ;)


Add validation of Git version

I guess we don't want to support old versions (app may work incorrectly), so add a check on git version. Currently we use 2.5, so let's take this one as a required version.

trying to implement this one

it was already merged before xmas - https://github.com/yu55/yagga/pull/46
2015-12-31 20:36 GMT+01:00 Marcin P<EMAIL_ADDRESS>
Where is the PR on this?
—
Reply to this email directly or view it on GitHub
https://github.com/yu55/yagga/issues/39#issuecomment-168237862.

it was already merged before xmas - https://github.com/yu55/yagga/pull/46
2015-12-31 20:36 GMT+01:00 Marcin P<EMAIL_ADDRESS>
Where is the PR on this?
—
Reply to this email directly or view it on GitHub
https://github.com/yu55/yagga/issues/39#issuecomment-168237862.


add pdf render

Related ARK-Builders/arklib#11

[kirill@fedora ark-cli]$ target/release/ark-cli render
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:166:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[kirill@fedora ark-cli]$ target/release/ark-cli render '/home/kirill/Papers/Chris Okasaki - Purely Functional Data Structures.pdf' high
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: LoadLibraryError(DlOpen { desc: "libpdfium.so: cannot open shared object file: No such file or directory" })', /tmp/nagato-chan/arklib/src/pdf.rs:19:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Do I need to install pdfium locally? Can we build it statically into ark-cli?

Downloaded the lib from here and done this:
export LD_LIBRARY_PATH="$(pwd)/libpdfium.so;$LD_LIBRARY_PATH"

Now ark-cli emitting nothing. We need to store result of rendering somewhere and present it to the user.

https://github.com/ARK-Builders/arklib/pull/12/commits/c7a0d58ab390a597405f412bc556cdf1287ecc16 should have embed Pdfium into ArkLib, and it does look like being pulled, but ark-cli still complains about lacking it:
[kirill@fedora ark-cli]$ target/release/ark-cli render '/home/kirill/Papers/Chris Okasaki - Purely Functional Data Structures.pdf' high
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: LoadLibraryError(DlOpen { desc: "libpdfium.so: cannot open shared object file: No such file or directory" })', /home/kirill/.cargo/git/checkouts/arklib-bfe1c25d108ecc84/c7a0d58/src/pdf.rs:28:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[kirill@fedora ark-cli]$ find -name libpdfium.so
./target/release/build/arklib-8a462be8b7e94253/out/libpdfium.so


Moving the existing reporting to the Node server backend

The ticket was first logged here:  https://github.com/HospitalRun/hospitalrun-frontend/issues/204
The move could be fairly straightforward for a Node developer, because: Javascript.
The concept here is that the frontend would now become more of a proxy to the node backend request vs. the system processing the business logic. To do that, the framework for making the call to an endpoint / endpoints on the server needs to be created and the report-generating logic from the following files needs to be moved from the frontend code base an appropriate place in the server codebase. That list is.

[ ] https://github.com/HospitalRun/hospitalrun-frontend/tree/master/app/inventory/reports/controller.js
[ ] https://github.com/HospitalRun/hospitalrun-frontend/tree/master/app/patients/reports/controller.js

Ideally the node endpoints would return the reports in the JSON API format since that is the default for Ember Data.

@jkleinsc can you review and confirm this?

@tangollama I updated your comment to point to the specific files that currently contain the JS logic to build the reports.  Also, I noted we should try to return report results in the JSON API format since Ember Data uses that.