sign+verify pair fails

Here is a minimal working example. You just need to add any key, certificate and CA certificate bundle.

import signxml
from lxml import etree

# Replace these before running the example.
SIGNATURE_KEYFILE = "my_privkey.pem"
SIGNATURE_CERTFILE = "my_cert.pem"
SIGNATURE_CA_CERTFILE = "ca_bundle_for_my_cert.pem"

KEY = open(SIGNATURE_KEYFILE, "rb").read()
CERT = open(SIGNATURE_CERTFILE, "rb").read()

NSMAP = {
    "soap": "http://www.w3.org/2003/05/soap-envelope",
    "wsse": "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd",
    "wsu": "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd",
    "wst": "http://docs.oasis-open.org/ws-sx/ws-trust/200512",
    "ds": "http://www.w3.org/2000/09/xmldsig#",  # Digital signatures
    "xenc": "http://www.w3.org/2001/04/xmlenc#",  # Encryption/Decryption
}

XML_DATA = """
<soap:Envelope
    xmlns:ds="%(ds)s"
    xmlns:soap="%(soap)s"
    xmlns:wsse="%(wsse)s"
    xmlns:wst="%(wst)s"
    xmlns:wsu="%(wsu)s"
    xmlns:xenc="%(xenc)s">
  <soap:Header>
    <wsse:Security mustunderstand="true">
      <wsu:Timestamp wsu:Id="wsuTimestamp-bc652a958f22bf12bf58de049e667767">
        <wsu:Created>2017-08-04T06:54:01Z</wsu:Created>
        <wsu:Expires>2017-08-04T09:24:01Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </soap:Header>
  <soap:Body><!-- more out-of-interest data here... --></soap:Body>
</soap:Envelope>
""" % NSMAP

soap_envelope = etree.fromstring(XML_DATA)
wsse_security = soap_envelope.find(".//{%s}%s" % (NSMAP["wsse"], "Security"))
wsu_timestamp = wsse_security.find(".//{%s}%s" % (NSMAP["wsu"], "Timestamp"))
wsu_timestamp_id = wsu_timestamp.get("{%s}%s" % (NSMAP["wsu"], "Id"))
reference_uris = ["#" + wsu_timestamp_id]

signer = signxml.XMLSigner(
    method=signxml.methods.detached,
    signature_algorithm="rsa-sha1",
    digest_algorithm='sha1',
    c14n_algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315'
)
signature = signer.sign(soap_envelope, key=KEY, cert=CERT, reference_uri=reference_uris, id_attribute="Id")
# Add id attribute to signature element, and add it to wsse
signature.set("Id", "Sig-b2dc77731c79e272df9a4004d1987cd7")
wsse_security.append(signature)

# Verify
verified_data = signxml.XMLVerifier().verify(
            soap_envelope, x509_cert=CERT, ca_pem_file=SIGNATURE_CA_CERTFILE,
            id_attribute="Id", expect_references=1).signed_xml

The problem is that verification fails with:
signxml.exceptions.InvalidSignature: Signature verification failed: bad signature
This seems impossible, because the signature was just created with the very same certificate.
If I replace "x509_cert=CERT" with "require_x509=True" then it doesn't make a difference.
What is wrong here?
Also, not really a big problem but the key and cert parameters for the sign() method contain the actual key/cert data, but the x509_cert parameter of the verify() method is a filename, and not the actual cert data. Was that intentional? What is the reson behind this?
Thanks!

Any clue on what can be the problem? :-(

Anyone who has the same problem can contact me

Hi @nagylzs. Sorry about missing your issue earlier. Can you please post your solution to the problem you encountered here for others to see? Thanks.

My solution was to create the digest and the signature on a lower level, using the cryptography module. So it does not use the signxml module anymore. I did it in a way that is specific to my app (I was in a hurry). I still don't know how to solve this with signxml.

Cool, thanks for the follow-up.

Nothing to do here, as far as I can tell.


Use julia version 1.10 on ci

I ran into some issues with the tests (see here) on ci after merging #163. Updating ci to run on julia v1.10 has solved this.
Closes #165

Nice catch, thanks! It's weird that the tests passed in the other PR but not on ci though...
Hopefully this works!

Yeah I am not quite sure why ci did not run on julia v1.9. I will try on a machine with v1.9 and check all works though.

CI is working now after this PR!


Href in templates result in CSP warning

I'm having trouble with the templates in our application.
Our application has a content security policy(CSP) enabled that does not allow inline javascript.
The templates used in this UI contain elements which have an href to "javascript:;".
This results in a CSP warning in our application every time we click a link in the swagger UI.
Is it possible to have the library updated with a CSP friendly version which does not contain this behavior?

Hi !
Ok, i'll include this in next release.


Tutorial dockerfiles (#463)

Build and push docker images for tutorials
Description
Please explain the changes you made, including a reference to the related issue if applicable
Checklist

[ ] Required by CI: Code is auto formatted using clang-format
[ ] While waiting for someone to review your request, please consider reviewing another open pull request to support the maintainers

The CI failure here is related to https://github.com/ros-planning/moveit2/pull/1426

@vatanaksoytezer could you please take a look at this PR and let me know your thoughts?
My goal was to achieve the following:

Provide the user a container in which they can immediately begin following the tutorials without having to set up anything for ROS
Generate images for each tutorial by following the instructions as closely as possible (Essentially making the Dockerfile is a test of the tutorial instructions)
Provide an image with all the tutorials completed such that the user can start a container and run all of the tutorial demos

Some details about my implementation:

The workflow triggers when there is a push to main, or a PR that changes moveit2_tutorials.repos, .docker/**, or doc/tutorials/**
I separated the base image job from building the tutorial images so that we don't have to build the entire moveit repo for each change once the PR is created
I use a changed-files action to rebuild the PR base image only when the new PR commit has changes to  moveit2_tutorials.repos, .docker/**, or doc/tutorials/** (The workflow runs when these files are different between main and the PR branch, but the changed-files action compares the PR's current commit with the previous one)
When a PR is submitted, we build a <image name>-PR-<branch name> image so we can push and reuse it if the PR files change and the base image doesn't need to be rebuilt. I still need to add a script to go through and delete all *-PR- images when it gets merged

A couple other details:

I built everything with DCMAKE_BUILD_TYPE=Debug, this was a suggestion to ease future debugging and testing of the images
I cloned and built all of moveit for the base image, recently the vcs import command stopped working in the moveit/moveit2 image. If you run the image and try a git pull on the package it will ask you for a username which causes the vcs import command in the dockerfile to fail. I considered adding some git config commands when building the base image to fix it, but if I'm rebuilding the package as Debug instead of Release I wasn't sure if there was a benefit in using the moveit/moveit2 image and switched to the ros:${ROS_DISTRO}-ros-base image instead

Finally, to everyone who got notifications for all my failed docker builds, I apologise.

@tylerjw do you mind taking a look at this as well?

@henningkayser @tylerjw in regards with what has been requested from TSC can you check this PR out?


Nested Stylesheets not included in live reloading

Taking a look at this:
live(1.0, true)
  path_query: /Users/willrax/Code/example/app/stylesheets/*.rb
  /Users/willrax/Code/example/app/stylesheets/application_stylesheet.rb
  /Users/willrax/Code/example/app/stylesheets/topics_screen_stylesheet.rb

I have a stylesheet in app/stylesheets/topics/user_screen_stylesheet.rb to match the structure of my screens which the path doesn't cover. I can take a stab at fixing this if you like :)

Scratch that. I can see these is fixed in master. :+1:
https://github.com/infinitered/rmq/blob/eb38820c44d416e4f9adf8a5a59b5cdb6e37e9cd/motion/ext.rb#L76


Annotations attached to anon functions are missing

Consider the following:
function testAnonFuncs() {
    var fn1 = @v1 function(int x, int y = 0, string... z) {
        int total = x + y;
    };
}

annotation v1 on function;

Here, if we debug and see, the annotation v1 attached to the anon function is missing from the annotation attachments in the AST node for it.

Tracked with https://github.com/ballerina-platform/ballerina-lang/issues/18207.


Unable to track your nick changing

If you /nick something you will be marked as offline in the chat dialog.

How do you propose tracking this?

periodic /whoami calls? Or tracking /nick sent to server?

So you only want to implement this for your own user, and not for everyone? What happens if someone else takes your old nick and then leaves?

I would think nothing happens? But maybe we do need this tracking of nick changes for all users/channels to keep the user list correct.

I don't see how to implement this, so I'm putting this issue in the fridge.
Maybe it's better to focus on getting some of the features in #444 in.


Dissociate satisfaction from the Node class

Probably as part of the satisfier work

The legacy satisfaction logic was removed. I'm working on a new one.


Missing slim shell stl file

You have a picture on the product page showing a slim shell version.
Can you add the stl file ?
Ref:

Url: https://lilygo.cc/products/t-embed

Already added


Add CodeQL to GitHub CI Action (fixes #2185)

Fixes #2185 (hopefully, we'll see).
This is an alternative approach to #2204.

Abandoning this in favour of the #2206 approach.


Support app_service and application_service_plan

Any reason why these are not included here?
I see them mentioned in the docs/defined_specs as:
app_service_plan     = "plan"
web_app                  = "app"
Although a web_app refers to TF resource "azurerm_app_service" so should be called app_service?
If they are missing, I'll go ahead and add them :)

Submitted PR #46 to solve this


middlewares refactor (fix #2279)

Moved middlewares into functions. Make it easier to config middleware for different command contexts.(fix #2279)

tests failed after merged in main to my branch to resolve conflict. seems the test also fails in main currently. something related to the decodeURIMiddleware

Thanks for the PR. However, after testing it locally, it alters the configureServer post hook invocation time. Overall it feels too big a refactor for a relatively minor feature/fix.


Add go mod support

This seems to be the way the golang community is going for dependency management. The biggest thing is that it makes it really easy to test local changes or forks of this repo for other modules using go mod as well. I have been locally generating this file for a while so I can use the following feature when making changes to the go-client locally.
replace gopkg.in/tumblr/go-collins.v0 => /home/username/code/go-collins

Yeah, this is awesome. Haven't been able to try it out much but definitely appreciated! Unless someone else gets to it before me I'll check it out late this week or early next week.
Unrelated, we might want to check if we can remove @schallert 's fork and just use the upstream. To be honest, I don't personally remember why it needed to be forked.


etcdadm scripts should be written to files at render phase, not up

right now etcdadm script is embedded in kube-aws binary and "materializes" itself only when we run "kube-aws up/update" which makes it harder to track full kluster config in git

@redbaron Thanks for the feedback 👍
Yes, it should be. It was even in the "remaining issues" list in “the original PR](https://github.com/kubernetes-incubator/kube-aws/pull/417) which introduced etcdadm.
How about scripts/ directory to store scripts like etcdadm?
Any preference on the naming of the directory?

why scripts is everything else is in write_files?

@redbaron My intention was to ensure users place only scripts inside the directory. The same as credentials for /etc/kubernetes/ssl.
Would you like to embed etcdadm directly into cloud-config-etcd like:
  - path: /opt/bin/etcdadm
    content: |
      // the content of etcdadm here

or anything else?

either way works for me. scripts is more convenient, but probably would require more work


Pixel api has been changed ? The bot does not detect the correct amount of available paint

Hi
Notpixel had to be updated, so now the bot doesn't detect the correct amount of available painting chances. This causes constant painting attempts, which the system can easily detect as cheating.

EDIT
I'm not entirely sure yet, but my problem seems to be some form of shadowban on the points awarded for painting.
If there is anyone here who knows anything about this, let me know. In the meantime, I'll let you know when I find out anything new.


AttributeError: 'BinanceFutures' object has no attribute 'ws'

Hi, I have Futures, Reading and European Options activated on my Binance API Key and also I've got it unresticted mode, its only for my IP address. Please help I have no idea what's wrong.
python main.py --demo --account binanceaccount1 --exchange binance --pair ZENUSDT --strategy Sample
INFO - Bot Mode : Trade INFO - pair: ZENUSDT INFO - timeframes: ['15m'] Traceback (most recent call last):   File "main.py", line 38, in <module>     bot.run()   ...   File "binance_futures_api.py", line 268, in _handle_response     raise BinanceAPIException(self.response) src.exchange.binance_futures.exceptions.BinanceAPIException: APIError(code=-2015): Invalid API-key, IP, or permissions for action, request ip: XXX.XXX.XXX.XXX INFO - Stopping Bot Exception ignored in: <function Bot.__del__ at 0x16a1676d0> ... AttributeError: 'BinanceFutures' object has no attribute 'ws'

Hi, you are using --demo flag which connects to binance testnet. Are you sure you are using their testnet api keys?

Do you know how i can create test api keys? I can't find anything on Binance's testnet website.

How do i fix this? I've already tried fixing my network but that doesn't seem to be the problem.
`
2023-08-18 19:02:23,338 - INFO - Websocket On Close: Restart
2023-08-18 19:02:26,020 - ERROR - Handshake status 400 Bad Request
2023-08-18 19:02:26,021 - ERROR - Traceback (most recent call last):
File "[REDACTED]/lib/python3.10/site-packages/websocket/_app.py", line 239, in run_forever
self.sock.connect(
...
File "[REDACTED]/lib/python3.10/site-packages/websocket/_handshake.py", line 140, in _get_resp_headers
raise WebSocketBadStatusException("Handshake status %d %s", status, status_message)
websocket._exceptions.WebSocketBadStatusException: Handshake status 400 Bad Request
2023-08-18 19:02:26,022 - INFO - Websocket On Close: Restart
... [REPEATED ERRORS OMITTED FOR BREVITY] ...
2023-08-18 19:02:36,512 - INFO - Websocket On Close: Restart
`

I see that you are trying to use python 3.10. Are you using Ubuntu 22.04?
matplotlib==3.7.1
numpy==1.24
ta-lib==0.4.24
pandas==1.5.3
bravado
websocket-client==0.52.0
hyperopt
pyti
google-api-python-client
oauth2client
discord-webhook==0.16.3

try to replace the contents of requirements.txt with the above code snippet and check!

How do i fix this? I've already tried fixing my network but that doesn't seem to be the problem. ` 2023-08-18 19:02:23,338 - INFO - Websocket On Close: Restart 2023-08-18 19:02:26,020 - ERROR - Handshake status 400 Bad Request 2023-08-18 19:02:26,021 - ERROR - Traceback (most recent call last): File "[REDACTED]/lib/python3.10/site-packages/websocket/_app.py", line 239, in run_forever self.sock.connect( ... File "[REDACTED]/lib/python3.10/site-packages/websocket/_handshake.py", line 140, in _get_resp_headers raise WebSocketBadStatusException("Handshake status %d %s", status, status_message) websocket._exceptions.WebSocketBadStatusException: Handshake status 400 Bad Request
2023-08-18 19:02:26,022 - INFO - Websocket On Close: Restart ... [REPEATED ERRORS OMITTED FOR BREVITY] ...
2023-08-18 19:02:36,512 - INFO - Websocket On Close: Restart `

Should be fixed now.


Simplify Arbitrary

This removes the { arbitrary: (fc) => } wrapper. It really shouldn't be necessary if we're careful with exports. kuvio for example isolates the Arbitrary stuff, though admittedly it's a bit simpler in that lib: https://github.com/skeate/kuvio/blob/main/package.json#L20-L26
I believe, however, that schemata-ts is already structured properly. The only references to Arbitrary I saw with a quick search in src/ were either (1) related to arbitraries or (2) in Schema.ts in the comments

I agree that this is better, and I would prefer it this way.
My one hesitation is that if fc is no longer behind a thunk would mean runtime errors if it's accidentally included in a front-end bundle.  An example would be a front-end project that's not tree-shaking properly.  It should but if it's required by a bundled app, and fast-check isn't installed (because it should be a dev-dep), then there will be runtime errors.
If arbitrary is behind a thunk, it will never be called and won't raise runtime errors

I don't think it's even really a tree-shaking concern at this point. The whole tree of arbitrary-related files is independent, as far as I can tell. I'll try generating a visualization later

Yeah, we definitely have a solid boundary between modules which import from fast-check, and ones that don't.  My argument, which I hope is wrong, is if a client bundles the entirety of schemata into a single file

Which actually makes me think of a second reason to keep the lazy arbitrary.
What if a node user (who bundles their library, i.e. webpack + node externals) wants to use schemata, but not install fast-check?  They would run into runtime errors in that case.
I realize that both of these require a big mistake (bundling schemata into a single file on 1) the client, or 2) the server without fast-check).  But it's at least something to think about

Third reason: typescript lib check, TS will throw an error if fast-check isn't installed, but might not if it were simply an argument from a function.

It can be listed as a peer dep?

I think what I did for kuvio would work here, too:

Create an index.ts which exports everything except Arbitrary-related code
Create an arbitrary.ts which exports all the Arbitrary stuff
Use package.json exports to manage those

Don't let consumers tap into the internal structure of the lib; (mostly) bundle it for them, so they don't feel compelled to write their own single-file bundle. Also address why Arbitrary is separated (I don't think I do this with kuvio, actually). If after all that they still manage to accidentally include fast-check, that's entirely on them.

Okay, here's what I'll do.  I'm still concerned that a lib-check from another lib might complain, so I'm going to checkout the branch and try to build without fast-check installed (while using schemas and transcoder).
Otherwise, I agree we should restrict the exports, but I don't think we should pre-bundle.
For the exports, I'm thinking index will contain all schemata / data types schemata-ts.  Additionally, each derivation will have its own export, schemata-ts/Transcoder.  This way if you're not using a derivation, we can omit its entire schemable.
One other point we might discuss is whether to keep src in npm.
Pros: source maps
Cons: bigger package size

Just to clarify, by "bundle" I meant like have an index.ts which exports everything. Not run a bundler.
Generally I just don't think * exports are a great idea; you could have multiple exports rather than one.
You can technically have sourcemaps without including the source files themselves (at least you could last time I messed with them). Doesn't really help from the package size front, though

In that case I need to add a version of arbitrary generation that takes fastcheck as an argument to kuvio.

We could also keep using the schemata's arbitrary pattern, while using kuvio for pattern-builder / patterns.  Alternatively, kuvio could make a version LazyArbitrary or something like that.


add node labels arg to windows setup script

@jackfrancis @JiangtianLi
Addresses #563
Adding KUBELET_NODE_LABELS to ArgList, need to figure out how to access the GetAgentKubernetesLabels function from here, if possible

@JamesEarle Thanks for fixing this. It is hard to see the diff, possibly due to line endings. Can you fix it?

@JiangtianLi my changes are the additions from line 294-299, adding "--node-labels $KUBELET_NODE_LABELS" to the args list. I haven't completed this though, as I'm not sure how to access the func GetAgentKubernetesLabelsin engine.go from the kuberneteswindowssetup.ps1, specifically in theWrite-KubernetesStartFiles`.
Do you know if I can do this? Working with Jack on it.

@JiangtianLi the changes should be easier to see in the most recent commit.

@JamesEarle You can take a look at how windowsTelemetryGUID is passed to ps1.


Danish translation

Hello. The "x minutes to read" currently is translated to "x minutter til læsning", which says something on the order of "x minutes until reading".
I would suggest "x minutters læsning" because it conveys the intended meaning.

@SonjaSaltzman Can you take a look at this localization issue?

@bodhigautam - could you please follow up? Sounds like a bad translation on the template?

@Powerhelmsman thanks for looping us in.
@SonjaSaltzman Yes, I am working on it.

I like the new "Læsetid: x minutter". It is a Little more formal though, but it is much better than the previous "x minutter til læsning".

Great, thanks for letting us know @HekiShavik :-)


aggregate holomap

Hi,
I'm trying to use datashader support for this plot below. The left is a image of histogram from 512 files with x axis as file number, y axis as bin number, and pixel intensity as counts, the right is a slice of histogram of a particular file. I can do holoview alone with about 20 slices, but with 512, it takes forever to render. Therefore I tried aggregate, but with no success. Aggregate does work on the example notebook "HoloViews_Datashader".
Any pointer to what might be the problem here? Thanks!

The notebook gives me the following traceback
IndexError                                Traceback (most recent call last)
/home/fz/anaconda3/lib/python3.5/site-packages/IPython/core/formatters.py in __call__(self, obj)
    337                 pass
    338             else:
--> 339                 return printer(obj)
    340             # Finally look for special method names
    341             method = _safe_get_formatter_method(obj, self.print_method)

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in pprint_display(obj)
    236     if not ip.display_formatter.formatters['text/plain'].pprint:
    237         return None
--> 238     return display(obj, raw=True)
    239
    240

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in display(obj, raw, **kwargs)
    222         html = layout_display(obj)
    223     elif isinstance(obj, (HoloMap, DynamicMap)):
--> 224         html = map_display(obj)
    225     else:
    226         return repr(obj) if raw else IPython.display.display(obj, **kwargs)

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in wrapped(element)
    147             if sys.version_info[0] < 3:
    148                 raise (t, v, tb)
--> 149             raise v.with_traceback(tb)
    150     return wrapped
    151

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in wrapped(element)
    114             html = fn(element,
    115                       max_frames=OutputMagic.options['max_frames'],
--> 116                       max_branches = OutputMagic.options['max_branches'])
    117
    118             # Only want to add to the archive for one display hook...

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in map_display(vmap, max_frames, max_branches)
    176         return sanitize_HTML(vmap)
    177
--> 178     return render(vmap)
    179
    180

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/ipython/display_hooks.py in render(obj, **kwargs)
     55     if renderer.fig == 'pdf':
     56         renderer = renderer.instance(fig='png')
---> 57     return renderer.html(obj, **kwargs)
     58
     59

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/plotting/renderer.py in html(self, obj, fmt, css, comm, **kwargs)
    260         code to initialize a Comm, if the plot supplies one.
    261         """
--> 262         plot, fmt =  self._validate(obj, fmt)
    263         figdata, _ = self(plot, fmt, **kwargs)
    264         if css is None: css = self.css

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/plotting/renderer.py in _validate(self, obj, fmt)
    196         if isinstance(obj, tuple(self.widgets.values())):
    197             return obj, 'html'
--> 198         plot = self.get_plot(obj, renderer=self)
    199
    200         fig_formats = self.mode_formats['fig'][self.mode]

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/plotting/renderer.py in get_plot(self_or_cls, obj, renderer)
    170                 continue
    171             if dmap.call_mode == 'key':
--> 172                 dmap[dmap._initial_key()]
    173             else:
    174                 try:

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/core/spaces.py in __getitem__(self, key)
    801         # Not a cross product and nothing cached so compute element.
    802         if cache is not None: return cache
--> 803         val = self._execute_callback(*tuple_key)
    804         if self.call_mode == 'counter':
    805             val = val[1]

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/core/spaces.py in _execute_callback(self, *args)
    637             flattened = [(k,v) for kws in kwarg_items for (k,v) in kws
    638                          if k not in kdims]
--> 639             retval = self.callback(*args, **dict(flattened))
    640         if self.call_mode=='key':
    641             return self._style(retval)

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/core/spaces.py in __call__(self, *args, **kwargs)
    431         ret = self._memoized.get(hashed_key, None)
    432         if hashed_key and ret is None:
--> 433             ret = self.callable_function(*args, **kwargs)
    434             self._memoized = {hashed_key : ret}
    435         return ret

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/util.py in dynamic_operation(*key, **kwargs)
     77             def dynamic_operation(*key, **kwargs):
     78                 self.p.kwargs.update(kwargs)
---> 79                 return self._process(map_obj[key], key)
     80         else:
     81             def dynamic_operation(*key, **kwargs):

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/util.py in _process(self, element, key)
     64             kwargs = {k: v for k, v in self.p.kwargs.items()
     65                       if k in self.p.operation.params()}
---> 66             return self.p.operation.process_element(element, key, **kwargs)
     67         else:
     68             return self.p.operation(element, **self.p.kwargs)

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/core/operation.py in process_element(self, element, key, **params)
    124         """
    125         self.p = param.ParamOverrides(self, params)
--> 126         return self._process(element, key)
    127
    128

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/operation/datashader.py in _process(self, element, key)
    175         agg_fn = self.p.aggregator
    176         category = agg_fn.column if isinstance(agg_fn, ds.count_cat) else None
--> 177         x, y, data, glyph = self.get_agg_data(element, category)
    178
    179         xstart, xend = self.p.x_range if self.p.x_range else data.range(x)

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/operation/datashader.py in get_agg_data(cls, obj, category)
    166                 df = pd.concat(paths)
    167         else:
--> 168             df = paths[0]
    169         if category and df[category].dtype.name != 'category':
    170             df[category] = df[category].astype('category')

IndexError: list index out of range

Out[28]:
b':DynamicMap   [i]'

It's not quite clear to me what you want to achieve here. If your data is already an Image, why do you need datashader at all or is it very large?

I'm trying to allow the slider to access any of the 512 histogram. When I have the i range from 0 to 512, it is taking forever to render the HoloMap. What else can I do here to make it faster. The image on the left is just a way for me to look at which file has meaningful distribution, so I can use the slider to interactively slice it and look into the actual histogram (which is on the right) of particular file.

What you want here is a DynamicMap, which would look something like this:
kdims=[hv.Dimension(i, range=(0, 511)]
vline = hv.DynamicMap(lambda i: hv.VLine(i), kdims=kdims)
cross_section = hv.DynamicMap(lambda i: rgb_hist.sample(x=i), kdims=kdims)
rgb_hist * vline  + cross_section

That works. Thanks.
Do I understand correctly that datashader cannot take image as input? What option do I have if I have one subplot being an image, and want to use datashader on other non-image subplot? There are still two more plots to add, and the dataset is a lot bigger.

Do I understand correctly that datashader cannot take image as input?

No, applying datashader to an image should work just fine. The issue above was that you were applying the datashading operation to a composite object, which also contained a VLine and a Curve. The datashading operations should always be applied just to the data that should actually be datashaded, and composing the plot into an overlay or layout should happen after you've applied the operations, e.g. this is valid:
kdims=[hv.Dimension(i, range=(0, 511)]
vline = hv.DynamicMap(lambda i: hv.VLine(i), kdims=kdims)
cross_section = hv.DynamicMap(lambda i: rgb_hist.sample(x=i), kdims=kdims)
aggregate(rgb_hist) * vline  + cross_section

Just tried that, and got this:
    150         elif isinstance(obj, Element):
    151             glyph = 'line' if isinstance(obj, Curve) else 'points'
--> 152             paths.append(PandasInterface.as_dframe(obj))
    153         if len(paths) > 1:
    154             if glyph == 'line':

/home/fz/anaconda3/lib/python3.5/site-packages/holoviews-1.7.dev8-py3.5.egg/holoviews/core/data/pandas.py in as_dframe(cls, dataset)
    229         if it already a dataframe type.
    230         """
--> 231         if issubclass(dataset.interface, PandasInterface):
    232             return dataset.data
    233         else:

AttributeError: 'Image' object has no attribute 'interface'```

Ah, that's a bug, there's a huge redesign of Image coming so it's not currently handled correctly, I'll make a small PR to fix it.

As a temporary workaround you could do this for now rgb_hist = hv.GridImage({'x': range(512), 'y': range(100), 'z': np.flipud(count_img)})

I'll close this for now. If you have any more support requests I'd recommend joining us on Gitter.


go.mod: using environment variable for replacement

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go111
Does this issue reproduce with the latest release?
Not an issue, but a request which should be very useful, especially for local editing.
What did you expect to see?
Looking to introduce a variable for being expended in go.mod:
module example

require example.io/foo

replace example.io/foo => $MYDIR/mod/foo

Or something like this might be better:
module example

using env MYDIR /default/local/path/if/env/not/offering
using arg MYARG "something default to the arg if command line not offering"

require example.io/foo

replace example.io/foo => $MYDIR/mod/foo

This will allow us to specify MYDIR working very much like a custom GOPATH.
$ export MYDIR=/path/to/my/project
$ go build # respects go.mod

Or sending MYARG to go.mod, for example of using -mod-arg or anything better:
$ go build -mod-arg MYARG=foobar

/cc @bcmills @myitcv

Why not fix this with tooling? For example, have you tried @rogpeppe's https://github.com/rogpeppe/gohack?

What is the underlying problem you want to solve?
Customization hooks add complexity, to both the implementation and the user-facing documentation, and the documentation for modules is already much more complex than I'd like. We should only add hooks if they provide a substantial enough benefit to offset that complexity, so we need to understand the concrete benefit you're hoping to provide.

@bcmills The underlying idea of adding using directive is to allow end configuration to go.mod. Especially when compiling for different conditions (platforms). The problem of the current replace directive is that it generally introduced a hard-coded path which is not portable. But the path is actually variable and unpredictable.
For example of this:
module example
require example.io/foo
replace example.io/foo => /path/to/my/module/base

It works for one dev, but complains for the other having /my/module/base instead of /path/to/my/module/base.
The other benefits of having using directive to introduce the variable is that users can mimic the GOPATH approach as like setting the replacement target as wished by operating devs. For example:
$ go build

and
$ MYDIR=/my/module/base go build

should work perfectly for this module differently:
module example

using env MYDIR /default/module/base

require example.io/foo v0.0.0
replace example.io/foo => $MYDIR/foo

I'm not sure if I understand the customization hooks you mentioned. But I think such using directives and $VAR should be just expended to a plain go.mod text (no $VARs) in memory and then being further processed by what it was like.
This brings great flexibility when using go mod and the go-module enabled go tools (go build, go install, etc.). The using directive and $MYDIR variables should not affect what go-modules have already done for go tools. It just improved the way that go.mod was interpreted.
Such an improvement will allow authors to define their own project-specific building variables (MYDIR) and allow taking variables from other build systems without the needs of touch go.mod. Which is very useful and important.
Introducing the using variables should also help improving documenting the build process. It should be much easier to document the using variables then telling how to edit go.mod to the right form before we can correctly get go build done.

I would consider creating a "template" file such as go.mod.in that would have the placeholders such as replace example.io/foo => MYDIR/foo and then using a sed command or Perl/Python/Go script to replace the placeholder with the desired value.  Personally I would also be against adding more complexity and customisation features to the modules file as it is increases cognitive load on users (and implementation complexity); also in this case it would make go.mod file not self-contained but dependent on the environment settings.

@dmitris @bcmills  I think when we're building a go program. We generally do go build directly (manually typing from a terminal) or indirectly (called from an other build system or scripts).
When we're building directly, aka. typing go build from a terminal, we will want to avoid hard coding the replacement target. For example of my presentation like example.io/foo => $MYDIR/foo. If all developers are from the same small office, it should be very much easy to comply to a common workspace path, e.g. /my/team/project. In this case the go.mod could work without touching any single line by defaulting MYDIR like this using env MYDIR /my/team/project. But when we're working with external hands, it might be very difficult to force others to go with /my/team/project setting. The go.mod of version go1.11 will ask us to fix replacement target first manually. I assume the maintainer will write some lines of docs telling about fixing the replacement target. Or in advance, (s)he might just write a helper script to do a automatic fixing and ask audiences to use that helper script, e.g. build.sh or makefile instead of calling go build directly. In this case, the scripts might be looking like this:
#!/bin/bash
# helper build script `build.sh`
sed 's|MYDIR|/a/variable/location/calculated/somehow|' > go.mod && go build

# helper `makefile` working with `make`
build:
        # do something to fix the `go.mod` file
        go build

It will definitely work and shouldn't be very difficult to apply. Or the author could also ask the audience to fix the replace example.io/foo => $MYDIR/foo line using their favorite editor manually.
When we're building indirectly, a hardcoded replacement should be easily fixed by other build systems, for example of seding the replacement target, but still the build is not portable. When introducing the using env/arg directives to make replacement targets variables/configurable, it should give go build a common interface to replacement the extra steps of seding replacement targets.
Another benefit when we have using env/arg is that we could mimic the GOPATH approach for each project. Like in the past, all we need to do is setting GOPATH to the right location and all go build works that easy way. The problem of GOPATH is about versioning dependencies (vendoring). With using env/arg directives, we're possible to do similar things like old days, the difference is that we use MYDIR rather than GOPATH, and different projects could have their own MYDIRs.
So that the using env/arg for go modules respects our go habit (the go-fashion).
Questions

But are these extra steps really necessary when we're working with go?
What if it goes recursively? Say if a required module needs a hardcode fixing too before go build is happy.
Is the using env/arg directives making things over complex or brining authors more flexibilities?
What using env/arg really changed to the go tools?

@duzy, I still don't understand what concrete problem you want to address with these replace directives. Why do all of the developers in your office need to replace some module?

Is it so that they can make edits to two modules simultaneously? (If so, that's #27542, and in the interim you might want to see if github.com/rogpeppe/gohack addresses your needs.)

Is it because you require a customized fork of some upstream dependency? If so, it seems like the replace directive ought to point to some stable module path (possibly hosted on a local GOPROXY server) rather than a local directory.

It it some other reason? If so, what?

@bcmills The replace is useful for us in different cases while using go.mod. We're generally working on multiple projects. Here're some example cases of using replace directive:

We're working with some common modules, which is in used by different projects. I think if we published these modules to GitHub (or other hosts), it should be working fine. But we're using the modules in-house only. So that replace came into help, supposed that example.io is our own repos site, we solve the issue like this:

module foo
require example.io/bar
replace example.io/bar /my/local/source/bar

This works perfectly me, but not for all in-house devs. Because devs could place bar in anywhere they want. So that all devs will have to change /my/local/source/bar to their favorite, and it conflicts every time they push the modification. In order to fix such conflicts, I proposed the using directive to rescue our life:
module foo
using env MYPAT /my/local/source
require example.io/bar
replace example.io/bar $MYPAT/bar

If this works in go1.12, you will save our life in this case.

An other example of using directive is that when we made some edits to a third-party module, say github.com/example/bar, we have to replace it somewhere else, say example.io/third/bar, to maintain our revisions:

module foo
using env MYPAT /my/local/source
require example.io/third/bar
replace example.io/third/bar $MYPAT/bar

I believe there could have many cases of using replace. The point of using go.mod instead of third-party similar tools is that we want to make life easier. It's our preference to using go tool rather then introducing more third-party tools.
I wish this help you to find out why the proposal useful.

@bcmills By the way, I have another proposal which is interesting. But I'm not sure if you like to add it. The second proposal is inspired by go test, which reads test cases from files like foo_test.go, so why not we do the similar approach rather using go.mod files.
For example, say if we have the package go/mod or go/tool/build (similar to testing), and we write go.mod in special Go files, say go_build.go or go_mod.go, and we define go.mod information in Go code instead of introducing go.mod directives:
package modinfo // or any special names
import (
    "go/tool/build"
)
func init() {
    build.Require([]string{
        ....
    })
}
func go_mod_require(p *build.Building) {
    ....
}
func go_build(p *build.Building) {
    ....
}

In Go code like this, we're possible to do anything we want! All we need to do is to populate go mod in Go API go/tool/build or go/mod, and using the similar approach of go test.

@duzy - if this is all in-house, why not put everything in a single repo? Then this problem goes away entirely, as does the overhead of maintaining separate repos. Especially if you are checking in go.mod files with such replacements, i.e. there is something permanent about them.
If these replace directives are temporary, then I think what you're effectively asking for is covered by #26640. With #26640 you would (via gohack or some similar approach) be able to do the environment variable expansion you want.

We're working with some common modules, which is in [use] by different projects.

In general the expectation is that those be published somewhere, even if it's only accessible within your local network. (For example, if your company is example.io, you could have the server for example.io serve meta tags pointing to an internal version-control server.)
If you need to edit those modules simultaneously, well-known environment variables don't seem like a scalable solution: if you need to fix an upstream module, how would you know which variables you need to set to work on it? I'd rather we address that use-case directly; see #27542.

when we made some edits to a third-party module, say github.com/example/bar, we have to replace it somewhere else, say example.io/third/bar, to maintain our revisions

That should be fine today: the target of a replace directive can be another module path. (It doesn't have to be a filesystem path.)

say […] we define go.mod information in Go code instead of introducing go.mod directives

I believe you can already do that today using a Git post-checkout hook or similar.

@duzy - if this is all in-house, why not put everything in a single repo? Then this problem goes away entirely, as does the overhead of maintaining separate repos. Especially if you are checking in go.mod files with such replacements, i.e. there is something permanent about them.

@myitcv I think in-house (office) development and separating the system into multiple repos (packages) are two different kind of problems. To decide whether you should go all in the same repos or split the system into many, it's up to the scale of the project or the design principle of the system. To me, if a part of the system is reusable to others or useful (feature) in the future, I would consider move it into a new package. It could make thing easier rather then introducing maintaining costs. In-house is not a good suggestion that everything should be in one repos.
The changes to those replace directives should not be called "temporary", it in fact a crucial step in the flow because without replace go mod don't work properly at all.
I think yes, if you're not going to add my second proposal, I'm interested to make it possible through the gohack approach. I think defining the go mod meta information or logic in go_build.go (go_tooling.go) files is more interesting then using go.mod files. It works just like go test. It's the go flavor.

We're working with some common modules, which is in [use] by different projects.

In general the expectation is that those be published somewhere, even if it's only accessible within your local network. (For example, if your company is example.io, you could have the server for example.io detect requests from internal IPs and serve meta tags pointing to an internal version-control server.)
Ideally, yes, by having our own example.io to serve as hosted-replacement is a practical approach and meets the package naming scheme [host]/[path]. But not all of us like it, reasons:

it requires to have real domain name and hosted meta tags plus potential bandwidth for transfering packages. I once did godev.io for my own purposes and it's working the same way as gopkg.io does but more flexible extensions. But turned our I'm not using godev.io again, because it costs me money on bandwidth to delegate the packages from another host like GitHub.

I believe you can already do that today using a Git post-checkout hook or similar.
I think git hook could be a solution too. But I prefer to see if my second proposal is possible now as it's more interesting than go mod. If go build can hook into my own go code GoRequire or GoBuild to complete a custom modification or logic, it could replace gopkg.io, godev.io and go mod in go flavor. So I'm interested to look into this when available.

So could you give me some suggestion on this idea:
package foo_tooling
import (
    "go/tooling"
)
func GoRequire(m *tooling.Mod) {
    var s = "example.io/third/bar"
    // do any calculation for `s`...
    m.Require(s)
}
func GoBuild(b *tooling.Build) {
    // do something meaningful here...
    b.Run()
}

Which work with go build (inspired by go test) that it invoke GoRequire and GoBuild at some point in the build flow?

@duzy

To me, if a part of the system is reusable to others or useful (feature) in the future, I would consider move it into a new package.

Just so we're not talking past each other on a couple of points.
In a pre-modules world, the repository was the unit of versioning. Repositories contain multiple (related) packages.
 The module is the unit of versioning. A repo can contain multiple modules.

I think we have the common understanding on these (modules, repos, packages). Just in the context of my case, I placed my common reusable packages in a place like the GOPATH directory. And I paced the package (in the context of saying) in such a directory (could be in a single repo). They're not belonging to any Go module. I like a place called MYDIR (in the previous posts) for me to contain all extracted useful Go code (in packages). This MYDIR could be in a (managing) repo or being a repo itself. I edit the Go code in MYDIR actively.

So my suggestion about moving towards a mono-repo is really motivated by the fact that Go modules enable multi-module repos, and it sounds like you have/need multiple modules. Of course you don't need to have multiple modules to justify a mono repo.

I think your suggestion is very positive and useful actually and the motivation is rational to me. I really appreciate that and I'm very happy to talk. I think in my context things are different as I'm not only working with Go modules and go-module is different then repo in my environment. So I think using the term go-module should help identifying the problem of replace with hardcoded paths (but not confusing with repo as a go-mod dir and a repo dir could be not related).

The changes to those replace directives should not be called "temporary", it in fact a crucial step in the flow because without replace go mod don't work properly at all.

Please can you share a few more details on your workflow? Because I can't see a reason for replace directives to be anything other than temporary.

So as said above, I have commonly shared packages in MYDIR. These packages are reused by many Go modules (other packages or utilities). In pre-modules environment, I have two options for other packages to import. 1) put those packages in GOPATH or 2) set GOPATH to $MYDIR:$GOPATH.
In Go module environment, things are different as it's not searching into GOPATH for modules. As we all know that Go module use a different approach to manage mods, and all downloaded mods are non-editable.
So my pre-module workflow was broken. Luckily the replace directive came into my search. I have to turn all packages into Go module (by initializing go.mod files). One additional benefit of using replace is that I could use a 'fake' module root/host. For example, I like to use a example.io/foo/blah import scheme while coding in Go. I don't need to care if example.io really exists or not. Because I'm making it working all right with replace directives. For example:
package main
import "example.io/foo/blah" // without Go module and `replace`, it was like "my/foo/blah"
func main() {
    blah.Hey()
}

And in go.mod I'm doing this:
module foo
require example.io/foo v0.0.0
replace example.io/foo /local/path/to/my/foo

This works for me to replace the GOPATH approach.
But the problems came into my mind, why do I hardcode the replace destination path /local/path/to/my/foo? This is not a perfect method in my sense. I understand that go.mod was designed to be edited by both human and go tool. But the problem is that only human knows what to replace.
I found that I'm not the only being troubled at this point. And I learned that someone is using go.mod and go.mod.local, go.mod.xxx variants to solve. But my question is still that why it's hardcoded and not a variable.
So that using env and using arg were born in my head. And go.mod should become:
module foo
using env MYDIR /local/path/to
require example.io/foo v0.0.0
replace example.io/foo $MYDIR/my/foo

This will solve things well:
$ MYDIR=/local/alt/path go build -o foo .

I think yes, if you're not going to add my second proposal, I'm interested to make it possible through the gohack approach.

If you do need multiple modules, then yes, I think the gohack approach (with or without go.mod.local) sounds like it will suit your needs. But a few more details will help.

The reason why I'd like to look into hack into "cmd/go/internal" is that I wish to make something like go_tooling.go to replace go.mod. The implementation of Go module (and other go tools) are internal. So that I have to hack into cmd/go to reuse the implementation.
The purpose of using go_tooling.go to replace go.mod is that Go code could perfectly describe what's required from a package/module, so that go.mod directives could be avoided. For example:
package foo_tooling
import "go/tooling" // or "cmd/go/tooling"
func GoRequire(a *tooling.Action) {
    ...
}
func GoBuild(a *tooling.Action) {
   ...
}
func GoDownload(a tooling.Action) {
   ...
}

And the package dir could be like:
$ ls
foo.go foo_test.go foo_tooling.go

The go.mod is replaced by foo_tooling.go.
While using Go code to describe the Go module requirements (require), we're possible to have unlimited possibility.

it requires to have real domain name and hosted meta tags plus potential bandwidth for transferring packages.

Last I checked a real domain name is $12/yr., and I'm not sure that you even need that: a reserved local IP address (even a loopback address to your local machine!) would suffice, as long as the <meta> tags point to someplace that you can resolve.

not always do we need to configure a remote setting to import a package -- I think this is one of the reason why replace was implemented.

I'm not sure what you mean. If you're importing a package from the same repository, you can use relative replace directives within the module. If you're importing from a different repository, you need to be able to resolve that repository somehow.

But I prefer to see if my second proposal is possible now as it's more interesting than go mod.

“More interesting” is a fine criterion for hobby projects, but it's not a good basis for inclusion in the Go toolchain: we try very hard to do make things “simple” rather than “interesting”.

A mechanical program to produce a go.mod file would add a huge amount of complexity — we (intentionally) do not execute any user-provided code during a go build.
Even environment substitution would add a lot of complexity in order to address a fairly niche use-case. Moreover, there already a lot of alternatives available, such as a local server with <meta> tags, a git post-checkout hook, or replace directives that point to symlinks that developers can customize.
I appreciate the thought you've put into this, but we won't be supporting these features in the go tool. (You are welcome to write whatever outside tooling you like to manage your own go.mod files, of course!)

it requires to have real domain name and hosted meta tags plus potential bandwidth for transferring packages.

Last I checked a real domain name is $12/yr., and I'm not sure that you even need that: a reserved local IP address (even a loopback address to your local machine!) would suffice, as long as the <meta> tags point to someplace that you can resolve.

not always do we need to configure a remote setting to import a package -- I think this is one of the reason why replace was implemented.

I'm not sure what you mean. If you're importing a package from the same repository, you can use relative replace directives within the module. If you're importing from a different repository, you need to be able to resolve that repository somehow.

For just building a project, do you think we (users) really need to buy a domain name and set a gopkg.in-like meta tags server to redirect import paths/versions. (If remember this right, a new version of meta tags requires the meta tags server to transfer the entire package/module via HTTPS.)
The old GOPATH approach was making go build dev so easy to setup. We just need to put any third party packages/module into GOPATH. It works well except that versioning/vendoring dependencies is difficult. And I don't think a meta-tags HTTP delegate server is making the
things easier.
It's nice to see the go.mod approach. It allows us to manage packages with the concept of module and avoid setting up the HTTP delegate server (meta-tags) to satisfy import. The meta-tags delegation is really a bad approach and you're suggesting me to use it.

But I prefer to see if my second proposal is possible now as it's more interesting than go mod.

“More interesting” is a fine criterion for hobby projects, but it's not a good basis for inclusion in the Go toolchain: we try very hard to do make things “simple” rather than “interesting”.

The second proposal is just another topic than theusing the directives which I'm very interesting to try. It's interesting because it's working very similar to the go test mechanism and it's possible to allow devs to achieve more than go.mod directives.
Regarding to the using directives proposal to go.mod, your only reason of rejection is that it's bringing more complexity to cmd/go. This is very interesting, I think I can understand if you just say "I'm not going to add it" instead of complexity.
I proposed the using directives is just wishing that go tool could become better. Thanks for responding anyway, the communication helped me to learn and think more.
Thanks again.

For just building a project, do you think we (users) really need to buy a domain name and set a gopkg.in-like meta tags server to redirect import paths/versions.

For “just building a project”, I would expect that most users either have a domain name already or use a (free) code hosting service. (If #28835 is accepted, that would potentially enable some other workflows as well, but if you want to interact with a global namespace of modules,  at some point you need a unique name within that namespace.)

It's not an good excuse to reject because of it's too complex to implement.

When I say it “would add a huge amount of complexity”, I mean it would be complex to use, not (just) complex to implement. The more features we add, the more features people have to understand in order to interact with the projects that use them.

When I say it “would add a huge amount of complexity”, I mean it would be complex to use, not (just) complex to implement. The more features we add, the more features people have to understand in order to interact with the projects that use them.

I would be agree with you that the more we add, the more complexity (of using it) it might be.
Comparing to the using directives and the real custom domain coding hosting server plus meta-tags, I don't believe that using is more complex to use. But I would be agree that a domain name being used as a package/module namespace is a good idea. So example.io/foo looks better to me than example/foo. But if you forces users to setup a real example.io code server in all cases, I insist that it's not easier than the using directives for go.mod.
Regarding to using the go_tooling.go approach as a replacement for go.mod, I always believe that it would be much easier to use a Go tooling API than a bunch of go.mod directives. As we're basically all Go devs, we all knows Go. So I believe that go_tooling.go wouldn't be more complex than writing directives in go.mod.
But I do believe that go_tooling.go should be much more complex than the using directives for go.mod.
If I'm going to implement a go/tooling API, I should make use of all the internal funcs already implemented for go.mod.
I like this second approach is because it's all in Go, no need to have extra grammars like go.mod. It's interesting because it would allows us (users/developers) to have unlimited ultra interaction with go tool.
For a summary:

using Go code to replace any meta-language (or domain language) like go.mod - Go itself as the meta language
to have a unlimited possibilities to extend go tool

I think this two principles make me feel interesting on this issue. As it's following initial saying of Go that Go is making programming interesting again (comparing to C/C++ or other languages).


Need assistance with BM71 firmware update with host uC

Hello,
My name is James Kimber and I am a student at The University of Akron, and I have a design project with a team of 3 other students and we have committed to creating a transmitter and receiver to do what we need it to do (not important) and we committed to using PIC24 uC's for both transmitter and receiver and BM71's for bluetooth communication between them. We are trying to update the firmware on the BM71's to the RN4870/RN4871 firmware so that we can use RN4870/RN4871 firmware to write script so that they will pair and bond automatically. (we know how to script them) We have successfully done this by updating the firmware using the firmware update tool through usb to computer, but we do not have the luxury of being able to use the update tool now that we have the PIC uC's and BM71's attached to our PCB's. How could we code the uC to update the BM71 firmware directly. We have reached out to Microchip, with no luck, and we are desperate. Please, PLEASE help.

I have not touched this in a LONG time, and when I did. The feature only partially worked.. I will gladly share the source that I had though.. Beyond providing you source, I don't think I have much more to offer.

BM71_flash_commands.c
``c
//------------------------------------------------------------------------------
//  Copyright(c)2018 Murphy Technology as an unpublished work.
//
//  The information contained herein is confidential property of Murphy Technology.
//  All rights reserved.  Reproduction, adaptation, or translation without the
//  express written consent of Murphy Technology is prohibited, except as allowed
//  under the copyright laws.
//------------------------------------------------------------------------------
#include <stdint.h>
#include <stdbool.h>
#include "BM71_flash_commands.h"
#include "BM71_flash_data.h"
#include "BM71.h"
#include "delay.h"
#include "debugAPI.h"
#include "driver_init.h"
#include "configAPI.h"
/-------------- DEFINITIONS -------------------------------------------------/
/-------------- TYPEDEFS ----------------------------------------------------/
/-------------- FUNCTION PROTOTYPES -----------------------------------------/
static bool OpenFlashMemory(void);
static void SetBufferAddress(uint16_t address, uint8_t lowByte, uint8_t highByte);
static bool Send128Bytes(uint16_t address, const uint8_t *data);
static bool Read128Bytes(uint16_t address);
static bool EndFlashMemoryAccess(void);
static bool EraseFlashMemory(void);
static uint8_t GetSizeOfMemBlock(void);
static bool SendConfigToEEPROM(void);
static bool CheckConfig(void);
static bool CompareEmptyMemory(uint16_t address);
static bool CompareMemory(uint16_t address, const uint8_t *expectedData);
static void SendFlashCommand(const uint8_t sendPacket, uint8_t sendSize, uint8_t recievePacket, uint8_t readSize);
/-------------- VARIABLE DEFINITIONS ----------------------------------------/
//Load the memoryBlock array from the "bluetooth_flash_data.h" header so we can read it here
extern const flash128_t memoryBlock[16];
///OPEN FLASH MEMORY
const uint8_t open_Transmit[17] = {0x01,0x05,0x04,0x0D,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
const uint8_t open_Response[21] = {0x04,0x0F,0x04,0x00,0x01,0x05,0x04,0x04,0x03,0x0B,0x00,0xFF,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00};
///READ COMMAND
const uint8_t read_Transmit[19] = {0x02,0xFF,0x0F,0x0E,0x00,0x10,0x01,0x0A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x80,0x00,0x00,0x00};
const uint8_t read_Response[19] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x86,0x00,0x10,0x01,0x82,0x00,0x00,0x00};
///ERASE ALL FLASH
const uint8_t erase_Transmit[19] = {0x02,0xFF,0x0F,0x0E,0x00,0x12,0x01,0x0A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x00,0x20,0x00,0x00};
const uint8_t erase_Response[27] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x0E,0x00,0x12,0x01,0x0A,0x00,0x00,0x00,0x00,0x40,0x03,0x00,0x00,0x20,0x00,0x00};
///WRITE COMMAND
const uint8_t write_Transmit[19] = {0x02,0xFF,0x0F,0x8E,0x00,0x11,0x01,0x8A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x80,0x00,0x00,0x00};
const uint8_t write_Response[19] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x06,0x00,0x11,0x01,0x02,0x00,0x00,0x00};
//CLOSE FLASH MEMORY
const uint8_t close_Transmit[7] = {0x01,0x06,0x04,0x03,0xFF,0x0F,0x00};
const uint8_t close_Response[14] = {0x04,0x0F,0x04,0x00,0x01,0x06,0x04,0x04,0x05,0x04,0x00,0xFF,0x0F,0x00};
/*******************************************************************************

Description: See the FLASH MSB and LSB address inside the write buffer.

*******************************************************************************/
static void SetBufferAddress(uint16_t address, uint8_t lowByte, uint8_t highByte)
{
//Set the MSB and LSB of the 2 byte address in the output buffer at the specified indexes
BM71_writeBuffer[lowByte] = (uint8_t) address;
BM71_writeBuffer[highByte] += (uint8_t) (address >> 8);
}
/*******************************************************************************

Description: BM71 command to open the flash for reading and writing.

*******************************************************************************/
static bool OpenFlashMemory(void)
{
SendFlashCommand(open_Transmit,sizeof(open_Transmit),BM71_readBuffer, sizeof(open_Response));
for(uint8_t i = 0; i < 19; i++)
{
    if(BM71_readBuffer[i] != open_Response[i])
    {
        return false;
    }
}
return true;

}
/*******************************************************************************

Description: Writes 128 bytes of data at the address specified.

*******************************************************************************/
static bool Send128Bytes(uint16_t address, const uint8_t *data)
{
//Clear the buffers
BM71_clearWriteBuffer();
BM71_clearReadBuffer();
//We first add the 19 byte write command to the beginning of the buffer
BM71_loadWriteBuffer(write_Transmit, sizeof(write_Transmit));

//We then update the buffer with the specified address to write 128 bytes to
SetBufferAddress(address, 11, 12);

//Place the data to be written after the command
for (uint8_t i = sizeof(write_Transmit); i < 147; i++)
{
    BM71_writeBuffer[i] = *data++;
}

SendFlashCommand(BM71_writeBuffer, 147, BM71_readBuffer, sizeof(write_Response));
//Check that the BT device responded with the
for(uint8_t i = 0; i < 19; i++)
{
    if(BM71_readBuffer[i] != write_Response[i])
    {
        return false;
    }
}
//If the response from the Bluetooth device was what was expected then return a true
return true;

}
/*******************************************************************************

Description: Reads out 128 bytes of data at the address specified from the

BM71 FLASH.
*******************************************************************************/
static bool Read128Bytes(uint16_t address)
{
//Clear the buffers
BM71_clearWriteBuffer();
BM71_clearReadBuffer();
//Populate the read command in the buffer
BM71_loadWriteBuffer(read_Transmit, sizeof(read_Transmit));
//Update the address of the read command in the buffer
SetBufferAddress(address, 11, 12);
//Send the read command
SendFlashCommand(BM71_writeBuffer, sizeof(read_Transmit), BM71_readBuffer, sizeof(BM71_readBuffer));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != read_Response[i])
{
return false;
}
}
//If the response from the Bluetooth device was what was expected then return a true
return true;
}

/*******************************************************************************

Description: Higher level command which sends 128 bytes, and then reads it back

to verify the data was written correctly to the BM71 flash.
*******************************************************************************/
static bool Write128BytesToFlash(uint16_t address, const uint8_t *data )
{
//Write data to the BM71
if(!Send128Bytes(address, data))
{
return false;
}
//Read the data back out
if(!Read128Bytes(address))
{
return false;
}
//Verify that the data we just read back matches what we wrote
for(uint8_t i = sizeof(read_Response); i < 128; i++)
{
//We compare byte by byte between the two buffers
if(BM71_readBuffer[i] != *data++)
{
//if the data does not match, we return a false
return false;
}
}
//If all data matched, we return a true.
return true;
}

/*******************************************************************************

Description: Close access to the BM71 FLASH.

*******************************************************************************/
static bool EndFlashMemoryAccess(void)
{
//Send the close access to the flash memory command and check the response
SendFlashCommand(close_Transmit,sizeof(close_Transmit),BM71_readBuffer, sizeof(close_Response));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != close_Response[i])
{
return false;
}
}
return true;
}
/*******************************************************************************

Description: Erase all flash memory of the BM71 in preperation of writing new

config.
*******************************************************************************/
static bool EraseFlashMemory(void)
{
SendFlashCommand(erase_Transmit,sizeof(erase_Transmit),BM71_readBuffer, sizeof(erase_Response));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != erase_Response[i])
{
return false;
}
}
brd_MsDelay(25);
return  true;
}

/*******************************************************************************

Description: Get the size of the configuration data that needs to be written
to flash.
*******************************************************************************/
static uint8_t GetSizeOfMemBlock()
{
//Divide the full size of the data memory by the block size to calculate how many blocks are in the struct
return sizeof(memoryBlock) / 130u;
}

/*******************************************************************************

Description: High level function that checks the size of the config to be

written and then begins writing all of the config blocks.
*******************************************************************************/
static bool SendConfigToEEPROM(void)
{
uint8_t sizeOfMemoryBlock = GetSizeOfMemBlock();
//cycle through each row/index in the "memoryBlock" array and update the
//flash memory.
for(uint8_t i = 0; i < sizeOfMemoryBlock; i++)
{
//each row has 128 bytes, so we set bytes to 128. We also send the address
if(!Write128BytesToFlash(memoryBlock[i].address, memoryBlock[i].data))
{
return false;
}
}
return true;
}

/*******************************************************************************

Description: Check if the config currently in FLASH matches the config we have

in firmware.
*******************************************************************************/
static bool CheckConfig(void)
{
uint8_t sizeOfMemoryBlock = GetSizeOfMemBlock();
bool isAddressInBlock;
uint8_t index = 0;
//This is a normal for loop, except we are using address instead of i
//address is also a 16bit word, not an 8 bit word because the
//bluetooth's addresses are all 16 bits.
//Since we are reading/writing 128 bytes at a time, we increment by
//0x0080 each iteration of the for loop. NOT the number 80, but 128 in hex.
//This causes us to have the address of the next 128 bytes in the memory each
//iteration of the for loop.
//Also, according to the BM71's documentation, the last address in the BM70's
//EEPROM is 0x1FF0. This is why we only loop to it then stop.
for(uint16_t address = 0x0000; address <= 0x1FF0; address += 0x0080)
{
//Reset address is found in the flash block flag
isAddressInBlock = false;
  //Reset the starting index location that we will start from when
  //searching the flash memory block
  index = 0;

  //Search through the Flash Block for the address, WHILE
  //we have not reached the end of the memory block's last index
  //AND
  //We have not found the memory address in the block

  //If we find the address, or we reach the end of the indexes
  //in the memory block then stop looking.
  while((index < sizeOfMemoryBlock) &&  !isAddressInBlock)
  {
      //if the current index of the memory block has the same
      //address as the one we are looking for set the isAddressInBlock flag true.
      if(memoryBlock[index].address == address)

          //Set the flag that the address was found in the memory block
          isAddressInBlock = true;
      //If the memory address was not found at the current index, then increment it
      //to the next index and keep looking
      else index++;
  }

  //If the address was found in the memory block
  if(isAddressInBlock)
  {
      //Then check that the 128 bytes after that address match the specified
      //bytes in the memory block
      if(!CompareMemory(address, memoryBlock[index].data))
          //if the 128 bytes did not match, then return with a false
          return false;

      //If the bytes did match, do nothing and continue testing the rest of
      //the memory
  }
  //Else if the address was not found in the flash memory block
  else
  {
      //Then assume that the 128 bytes after this address should be in the
      //erased state "0xFF". Check that all the following 128 bytes are
      //set to "0xFF". If the address is not found in the memory block it
      //is to be assumed it is a fully erased block.
      if(!CompareEmptyMemory(address))

          //If the 128 bytes did not all return as "0xFF" then there is
          //a data mismatch, and return as false.
          return false;

      //If all of the 128 bytes are blank then do nothing and continue testing
      //the rest of the memory
  }

}
//If we reach this point, then we have checked all of the flash memory and
//everything matched (Since we did not return false yet), so return true.
return true;
}

/*******************************************************************************

Description: Verify that the the data in FLASH has been cleared properly.

*******************************************************************************/
static bool CompareEmptyMemory(uint16_t address)
{
if(!Read128Bytes(address))
{
return false;
}
//If the 128 bytes returned from the BM71 is not all set to 0xFF (Not Empty)
//we return a false
//
//We start at i = sizeof(read_Response) to skip the response command sent back. We only care
//about the data returned, not the response command.
//
//We also use i < sizeof(BM71_readBuffer) to make sure we read all the way to the end of the buffer
//to read the full 128 bytes.

for(uint8_t i = sizeof(read_Response); i < sizeof(BM71_readBuffer); i++)
{
    if(BM71_readBuffer[i] != 0xFF)
    {
        return false;
    }
}
//If the values all matched then return true;
return true;

}
/*******************************************************************************

Description: Compare the data that we just read from the BM71 with what we

expected as a response.
*******************************************************************************/
static bool CompareMemory(uint16_t address, const uint8_t *expectedData)
{
BM71_clearReadBuffer();
Read128Bytes(address);
//If the 128 bytes returned from the BM71 does not match the 128 bytes passed
//into the *expectedData array then return false
//
//We start at i = sizeof(read_Response) to skip the response command sent back. We only care
//about the data returned, not the response command.
//
//We also use i < sizeof(BM71_readBuffer) to make sure we read all the way to the end of the buffer
//to read the full 128 bytes.
for(uint8_t i = sizeof(read_Response); i < sizeof(BM71_readBuffer); i++)
{
if(BM71_readBuffer[i] != *expectedData++)
{
return false;
}
}
//If the values all matched then return true;
return true;
}

/*******************************************************************************

Description: Low level function for writing a command to the BM71 over UART.

*******************************************************************************/
static void SendFlashCommand(const uint8_t *sendPacket, uint8_t sendSize, uint8_t recievePacket, uint8_t readSize)
{
//Make sure the RX ring buffer is empty
usart_async_flush_rx_buffer(&BT_UART);
BM71_clearReadBuffer();
while(io_write(&BT_UART.io, (const uint8_t)sendPacket, sendSize) == ERR_NO_RESOURCE)
{
; //Wait until the UART is ready to write more data
}
//Wait a bit before checking the buffer for any response
brd_MsDelay(20);
//Read out the response into the receive packet
io_read(&BT_UART.io, recievePacket, readSize);
}
/*******************************************************************************

Description: Main function used to read the flash memory. Verify that it

matches what we have stored in our flash. If not, then we begin the process

of deleting the BM71 flash, and then writing the new config.
*******************************************************************************/
bool BM71_checkAndUpdateFlash(void)
{
bool retVal = false;
uint8_t bluetoothConfigVersion = 0xFF;
// Get the Bluetooth Version stored in the NVM Device Config
bluetoothConfigVersion = config_getBluetoothConfigVersion();
// If the config version is 0xFF, that means this is a new device.
// Set the config version to 0x00
if(0xFF == bluetoothConfigVersion)
{
config_setBluetoothConfigVersion(0x00);
// Get the Bluetooth Version stored in the NVM Device Config
bluetoothConfigVersion = config_getBluetoothConfigVersion();
}
if(bluetoothConfigVersion < BLUETOOTH_CONFIG_VERSION)
{
// Config version stored in NVM is less than the version indicated by the FW.
// Attempt to update the BM71 configuration.
//First enter test mode so we can access the BM71 Memory
BM71_ResetToTestMode();
  DEBUG_println(BLE, "New Bluetooth config available..\n\r");
  retVal = OpenFlashMemory();
  if(retVal)
  {
      DEBUG_println(BLE, "Comparing against current BM71 config..\n\r");
      retVal = CheckConfig();
      if(retVal)
      {
          DEBUG_println(BLE, "Bluetooth Config is up to date!\n\r");
          config_setBluetoothConfigVersion(BLUETOOTH_CONFIG_VERSION);
      }
      else
      {
          DEBUG_println(BLE, "BM71 config is out of date. Starting update... \n\r");
          retVal = EraseFlashMemory();
          if(retVal)
          {
              retVal = SendConfigToEEPROM();
              if(retVal)
              {
                  DEBUG_println(BLE, "New config applied successfully!\n\r");
                  config_setBluetoothConfigVersion(BLUETOOTH_CONFIG_VERSION);
              }
              else
              {
                  DEBUG_println(BLE, "Failed to apply new config\n\r");
              }
          }
          else
          {
              DEBUG_println(BLE, "Failed to erase flash memory.\n\r");
          }
      }
      EndFlashMemoryAccess();
  }
  else
  {
      DEBUG_println(BLE, "Failed to open flash memory!\n\r");
  }

}
else
{
DEBUG_println(BLE, "Bluetooth Config is up to date!\n\r");
retVal = true;
}
return retVal;
}

@jkimber09 I've went ahead and my repository public where I was attempting to use the BM71. It can be found at the link below.
https://github.com/stephendpmurphy/OctaneMate.Firmware
You should focus on the folder called ble within the source. Specifically the BM71_flash_commands.* and BM71_flah_data.h files.
Best of luck.


Suggestion: add a little info menu!

Also can you add a little wiki or help icon that can open up a modal popup menu that informs a user of possible keys and functionality? yes the UI is intuitive enough and the GitHub docs but it would be helpful addon too for end users who end up using the player!

Hi, thanks for the suggestion.
Currently I don't intend to do this as part of the core component because there is already the flexibility to add custom buttons. The developer can add an info menu or help popup via a custom button action along with a descriptive label (see readme https://github.com/lewhunt/react-tv-player?tab=readme-ov-file#custom-buttons).


feat/FOROME-1173" create pagination list

Task
Also move folder with shodow scroller to components folder.

Go to any XL dataset, open FR and choose Panels attribute and start filtering results by using search. For example you can type in 'x' or 'z'. Results will be filtered. But when you change the page forwards multiple times, and try to by for the same symbol, you'll get different results. If you try to type in more symbols (for example 'zz'), the whole application freezes and stops responding.

UPD: Decided to go back to the previous design.


about repo dependencies

can youo tell us which version of gym and atari-py you have used for this repo?

Sure, but give me 2 days and I will be able to tell you, apologize for the inconvenience but I don't have access to the original code now.

its 🆗
---- Replied Message ----
| From | Davide @.> |
| Date | 10/10/2022 13:10 |
| To | @.> |
| Cc |<EMAIL_ADDRESS>|
| Subject | Re: [davide97l/rl-policies-attacks-defenses] about repo dependencies (Issue #21) |
Sure, but give me 2 days and I will be able to tell you, apologize for the inconvenience but I don't have access to the original code now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Any updates regarding this issue.

pip install gym[atari]==0.22.0

can youo tell us which version of gym and atari-py you have used for this repo? I also want to know,this is important for me,than you!

您能告诉我们您为此存储库使用了哪个版本的 gym 和 Atari-py 吗？

Hello, I have encountered the same issue. Could you please let me know how you solved it?


Warning: setState(...)

I get the following error when using version 2.0.0
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the RetinaImage component.

How can I help resolve this?

@Jan-Jan I would add console.log before every setState in this module and see where and why setState is being called so early.

Would appreciate a PR to fix the problem :)

@KyleAMathews I have the same problem. And state set your module.

@KyleAMathews Will you fix it bug ?

@igor-lemon happy to merge a PR from you fixing the problem. I'm not actively using this module right now.

@KyleAMathews Ok. I'll check and will try to fix.


Update for v2 "API"

Prosody just released the v2 api. Can this be updated? :)

As far as I can see, the only real change is checking whether the MIME type specified with the XMPP slot request matches the MIME type specified with the HTTP PUT request.  I see no real gain in this check, so I'm not sure this warrants the additional complexity of supporting both versions.


Vscode Terminal Context Aware colors [ stderr ]

VSCode Version: Version 1.22.2 (1.22.2)
OS Version: MacOSX

Suggestion:
* vscode can identify programming errors  python err , java err  and show them in different colors ( or atleast stderr can be shown in different color )
* An additional flag to toggle it would be much nicer :)

No plans to do this, see https://github.com/Microsoft/node-pty/issues/71 for a discussion


Question :: Can we load fonts on demand from a network ttf file?

Is it possible to not bundle the font files via pubsepc.yaml file and load them dynamically.
Can NetworkAssetBundle be used for this purpose? Is there an example implementation of such a scenario somewhere?

dup of #15386 ?

Is there a list of the default fonts supported out of box?

Is there a possible workaround ?

@Hixie .. any ideas on a workaround and is there a list of out of box fonts included in the platform

You can ship whatever fonts you want with Flutter and use them. See https://flutter.io/cookbook/design/fonts/

The fonts available by default are whatever fonts ship with the operating system.
Closing as dupe of #15386.

Progress at #17910


FileNotFoundException for ~/.gradle/daemon/7.2/report.dtd

I have integrated the plugin following the instructions in the README and set an input and output path. I have confirmed that the input file exists, but when I try to run the jacocoToCobertura task I get a FileNotFoundException. It seems the plugin is looking for a file called ~/.gradle/daemon/7.2/report.dtd but this file does not exist on my system.
% ./gradlew --version

------------------------------------------------------------
Gradle 7.2
------------------------------------------------------------

Build time:   2021-08-17 09:59:03 UTC
Revision:     a773786b58bb28710e3dc96c4d1a7063628952ad

Kotlin:       1.5.21
Groovy:       3.0.8
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          19.0.1 (Oracle Corporation 19.0.1+10-21)
OS:           Mac OS X 12.6.1 aarch64

12:26:04 PM: Executing task 'app:jacocoToCobertura'...

Executing tasks: [app:jacocoToCobertura] in project <REDACTED>

> Configure project :app
inputPath: '<REDACTED>/android/app/build/reports/jacoco/testDevelopEnvironmentDebugUnitTestCoverage/testDevelopEnvironmentDebugUnitTestCoverage.xml'

> Task :app:jacocoToCobertura
Conversion jacoco report to cobertura
Error while running JacocoToCobertura conversion: `Loading Jacoco report error: `(was java.io.FileNotFoundException) /Users/eliotlash/.gradle/daemon/7.2/report.dtd (No such file or directory)
 at [row,col {unknown-source}]: [1,124]`

BUILD SUCCESSFUL in 147ms
1 actionable task: 1 executed

Build Analyzer results available
12:26:04 PM: Task execution finished 'app:jacocoToCobertura'.

(This is occurring in a work project under NDA so I have redacted some of the build details). I added a println statement to log the input path.

Not sure what it can be. The only place I see report.dtd is in the jacoco report. In my jacoco report xml I see something like:
<!DOCTYPE report PUBLIC "-//JACOCO//DTD Report 1.1//EN" "report.dtd">

but is not something I really care about... maybe the xml parser lib but I did nothing to change or don't know how it's modified.
are you using jacoco 0.8.8? any special jacoco xml report configuration?

Thanks for the reply. I was using the configuration from https://blog.canopas.com/android-code-coverage-using-jacoco-6639a1fc4293
I was using jacoco 0.8.7. I was blocked by this so I decided to deintegrate this gradle plugin and use cover2cover instead. So if you want I can close the issue, but I'm happy to keep it open and continue to troubleshoot to help others who might run into the same issue in the future.

OK, so this is pretty hacky but I am trying out this plugin again (cover2cover is generating invalid XML) and I figured out a workaround... I just downloaded https://github.com/jacoco/jacoco/blob/master/org.jacoco.report/src/org/jacoco/report/xml/report.dtd into ~/.gradle/daemon/7.2/report.dtd 🤷♂

I don't see why it really looks for the dtd...
I tried with jacoco 0.8.7 but no matter how hard I try to screw up the DOCTYPE tag
<!DOCTYPE report PUBLIC "-//JACOCO//DTD Report 1.1//EN" "report.dtd"> (using a bad path, bad version, wrong file name, without the tag) I get no error.

Hello, I tried  on macOS & Linux jdk 11 &. 17. The xml library I use is SimpleXML I can't see where or why it cares about the dtd, I couldn't manage to make it care.
I may try to switch to another one when I'll have some time as this one is quite old, but wanted something easy and fast to implement.

had the same problem in a simply spring-kotlin-multimodule project with open-jdk-17, gradle 8.0.2 and the default used jacoco plugin. I also use macOS. I switched back to kover and with that it works fine.

So this is the solution I eventually landed at that's compatible with running in CI. In the gradle task, I download the DTD to the working directory:
jacocoToCobertura {
    def inputDir = "$buildDir/reports/jacoco/testDevelopEnvironmentDebugUnitTestCoverage"
    def inputFilePath = "$inputDir/testDevelopEnvironmentDebugUnitTestCoverage.xml"

    // Workaround for parse error: Download JaCoCo DTD to working directory
    def workingDir = new File(".").getAbsoluteFile().getParent()
    def f = new File("$workingDir/report.dtd")
    if (!f.exists()) {
        new URL('https://raw.githubusercontent.com/jacoco/jacoco/master/org.jacoco.report/src/org/jacoco/report/xml/report.dtd')
                .withInputStream{ i -> f.withOutputStream{ it << i }}
    }

    def outDir = "${buildDir}/reports/cobertura"
    file(outDir).mkdirs()
    inputFile.set(file(inputFilePath))
    outputFile.set(file("$outDir/cobertura.xml"))
}

This vexing issue has been annoying me also for the past year, but FWIW, the solution above (thanks @fadookie!) led me to adopt this workaround:
tasks.named('jacocoToCobertura').configure {
    dependsOn jacocoTestReport
    doFirst {
        def jacocoClasspathUrls = jacocoTestReport.jacocoClasspath.collect { it.toURI().toURL() }
        def classloader = new URLClassLoader(jacocoClasspathUrls as URL[])
        def jacocoReportsDir = jacocoTestReport.reports.xml.outputLocation.get().asFile.parent
        new File(jacocoReportsDir, 'report.dtd').withWriter {
            it << classloader.getResourceAsStream('org/jacoco/report/xml/report.dtd')
        }
    }
}

The key difference to the previous solution is that I'm unpacking the report.dtd directly from Gradle's JaCoCo classpath instead of downloading it from the internet, and dropping it into build/reports/jacoco instead of the Gradle daemon's global working directory.

My workaround is just to remove the doctype:

jacocoToCobertura {

    // Remove the DOCTYPE otherwise the conversion fails with
    // Error while running JacocoToCobertura conversion: `Loading Jacoco report error: `(was java.io.FileNotFoundException) .gradle/daemon/8.0.2/report.dtd (No such file or directory)
    // See https://github.com/razvn/jacoco-to-cobertura-gradle-plugin/issues/11

    val reportFile = file("$buildDir/reports/kover/report.xml")
    val inputWithoutDoctypeFile = file("$buildDir/reports/kover/report-without-doctype.xml")
    val docTypeToRemove = "<!DOCTYPE report PUBLIC \"-//JACOCO//DTD Report 1.1//EN\" \"report.dtd\">"
    inputWithoutDoctypeFile.writeText(
        reportFile.readText().replace(docTypeToRemove, "")
    )

    inputFile.set(inputWithoutDoctypeFile)
    outputFile.set(file("$buildDir/reports/kover/cobertura.xml"))
}

Similar to the above ^
tasks.jacocoToCobertura {
    val jacocoReport = file("$buildDir/reports/jacoco/test/jacocoTestReport.xml")
    onlyIf { jacocoReport.exists() }

    doFirst {
        jacocoReport.readText().replace("<!DOCTYPE[^>]*>".toRegex(), "").let {
            jacocoReport.writeText(it)
        }
    }
}

Thanks, everyone. I now am getting this all of a sudden as well. It must the due to a new dependency I've added recently, but I did neither touch Gradle nor this plugin 🤷
Anyway, if you adapt the above solutions a little bit, you reach this one that is generic and works by just utilizing the plugin's task's input:
// https://github.com/razvn/jacoco-to-cobertura-gradle-plugin/issues/11
tasks.named<JacocoToCoberturaTask>(JacocoToCoberturaPlugin.TASK_NAME) {
    doFirst {
        val inputFile = inputFile.asFile.get()
        inputFile.writeText(
            inputFile.readText().replace("<!DOCTYPE[^>]*>".toRegex(), "")
        )
    }
}


Update to OpenGeode new version

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


Bug with CF.lumen App

Hi, I discovered a bug with the CF.lumen app. CF.lumen is like the Twilight app, a light filter app. When CF.lumen is active, the overlay is interfering with the App, the menues are visually existing but not functional. It's not possible to interact with the menus and they are visually overlapping each other.

Steps to reproduce:

CF.lumen app installed and running (a color changing overlay must be active)

Digibyte-App try to send, receive or go to settings

It's a security countermeasure, apps that overlay can capture content and interact with the underlying app. I'll chat about this with the team.