SOS button Developer

Hello i search a developer what my can make a SOS button to the Traccar Client ( iOS / Android )
When i Press the Button then musst on the Web begin flashing....
Also i search people what my can make on the Web a special solution with push or IP call...
Please send my a msg when you can doing this to<EMAIL_ADDRESS>

This feature would be really cool. Have a look on this.

@dschense can you my give your skype or email ?

I am at work atm will contact you this evening.. But I am not that good with this coding stuff... Maybe others are also interested in this and can help.

Any progress on this?

I did android sos button functionality for similar project, please contract me.

Please send my  app to<EMAIL_ADDRESS>


First pass at removing set-output

Work in progress. But feedback is welcome.
Description
set-output has been deprecated. See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/.
Motivation and context
This will remove deprecated notices in workflow summaries.
How has this been tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING.md document.
[ ] I have added tests to cover my changes.

grin @desrosj Only now seeing your PR, I was working on the same thing ;-)

I've addressed a handful of the feedback given. I also added some brief inline documentation to the tests.

@ramsey Would you happen to be able to give some guidance ? Would be nice if the CI related PRs (this one and #237) could get merged soonish, so I can pull the PR for the feature request in #234

Thank you! I've been away for a bit, but I'll take a look at this today.

I won't have a chance to circle back on this until Wednesday. @ramsey feel free to make any changes to wrap this up if you'd like to get it out sooner!

I saw the build errors in #237 but assumed they'd go away when merged into this PR. I'll try to find some time this week to see if I can help resolve things to get this merged and tagged.
Thanks!

I saw the build errors in #237 but assumed they'd go away when merged into this PR. I'll try to find some time this week to see if I can help resolve things to get this merged and tagged.

They will (should) once the strict comparisons have been changed to regex/wildcard-based comparisons for the tests I flagged up above ;-)

Anything I can do to help move this forward ?

Anything I can do to help move this forward ?

I haven't had a chance to circle back to this because of a few other things going on at the moment. If you'd like to figure out the needed test adjustments, happy to hand the rest of this over to someone else in the interest of seeing this fixed/released.

Anything I can do to help move this forward ?

I haven't had a chance to circle back to this because of a few other things going on at the moment. I'll likely have time next week, but if you'd like to figure out the needed test adjustments, I'm more than happy to hand the rest of this over to someone else in the interest of seeing this fixed/released.

Okay, so I've just spend a couple of hours trying to get this to work and in the end I ended up in the Tcl manual and it looks like I may have actually managed to get it working... I need to run some more tests to be sure, but I'm hoping to send in a PR later today combining @desrosj commits from this PR with the fix I found.

Wowie! Tested (including deliberately breaking tests to make sure the solution will correctly fail tests when needed) and I now have a 🟢 build. Will clean up my WIP branch and pull it momentarily.

I've opened PR #238 which builds onto this one and gets us to a green CI build again.


Update the storage test cases which include duplicated test parameter key

Issue:
When test parameter with duplicated key, only final key parameter will be parsed,
e.g. the SCSI=0,1,2, Dynamic;SCSI=0,2,Dynamic have same keys.
So all the cases with duplicated key parameter will be impacted, currently I see some storage test cases have duplicated key in the FunctionTests-Storage.xml.
Root cause:
In CommonFunctions.psm1, the function Parse-TestParameters will define hashtable $testParameters, which set $testParams[$name] = $value, duplicated key will be overwritten.
Resolution:

update test framework testParameters as not hashtable, seems it is complex to change, since some script also use it as hashtable
update test cases xml.

Question:
Could you please help to confirm which method is better? If need update storage xml, I can update it.

I‘m working on this issue, done 80%, after run on all the related test cases, will submit PR.


Tasks that use CLI that use Kraft cluster.id (ie. kafka-storage) fail when cluster.id that start with hyphen

I started with a ZK cluster with id "-v5on6u0TVW2BvW4hazZTw" ... after upgrading to Kraft using the migration playbook, I cannot run the playbook again to change broker properties, as the task "Format Storage Directory" uses the kafka-storage CLI without quoting the cluster.id
See attached images including running the command manually, as the Ansible error output was not clear enough

But it seems that quoting the argument doesn't work either

thanks @DennisFederico  for pointing this out, I will fix this bug

closing since the fix has been merged


No warning/error for overwriting a std lib file

Only repros with latest packages, so create a new venv for the kernel
Create a file in the workspace called random.py
Create a notebook and run a cell.
the cell succeeds, which causes Display error about overriding builtin modules (without Python daemon to fail.

Problem is latest version of IPykernel prevents shadowing of builtin packages when starting a kernel


Dynamic write access to namespaces

Namespaces can be accessed like maps, but they are read-only when accessed dynamically:
~> echo $edit:[max-height]
30
~> edit:[max-height] = 20
Exception: assoc is not supported
[tty], line 1: edit:[max-height] = 20

It will remain impossible to create new names in namespaces dynamically; this is a feature, not a bug.


\toggle causes the entire  to be removed from DOM when clicked if converted using MathJax.tex2chtml

Issue Summary
\toggle causes the entire  to be removed from DOM when clicked if converted using MathJax.tex2chtml (using the method from the example https://github.com/mathjax/MathJax-demos-web/blob/master/input-tex2chtml.html.md)
This does not seem to happen if the tex is parsed from DOM text.
Steps to Reproduce:
Fiddle link: https://jsfiddle.net/wq8gvca3/
Source:

Clicking on the toggle renders the entire document blank, and shows the following in the console.
Uncaught TypeError: Cannot read property 'parentNode' of null
    at c.parent (tex-chtml-full.js:1)
    at c.insert (tex-chtml-full.js:1)
    at e.l.updateDocument (tex-chtml-full.js:1)
    at Object.renderMath (tex-chtml-full.js:1)
    at v.renderMath (tex-chtml-full.js:1)
    at e.n.rerender (tex-chtml-full.js:1)
    at HTMLElement.<anonymous> (tex-chtml-full.js:1)

Preliminary debugging suggests the removal came from:
https://github.com/mathjax/MathJax-src/blob/1d5ce9837c82f1d12efec8da829c2138bd640c08/ts/handlers/html/HTMLMathItem.ts#L87
Seems like the start node was set to the  element rather than the element that's actual rendered.
Technical details:

MathJax Version: 3.0.5 (tex-chtml-full)
Client OS: Windows 10 1909
Browser: Chrome 83.0.4103.116

Supporting information:

Thanks for the report.  I have verified the issue, and will include a fix in the next release.  In the meantime, you can use the following in your file before the line that loads tex-chtml-full.js:

This will patch the CommonHTML output to resolve the issue for now until it is fixed officially.

Thank you!

Fixed in v3.1 released today.


Remove temporary time stepper components

This PR removes the old temporary time stepper components. I forgot to remove this in #2187.

bors r+

bors r+


Timeout waiting for gdb server to start

I am trying to debug a board with an LPC1768 processor with MBED Studio 1.4.1 but every time I try to start the debugger I get the message "Timeout waiting for gdb server to start". Yet, when I start the debugger with "pyocd --target lpc1768" it starts and keeps running. I looked up the problem and they suggested trying to run pyocd with a supplied pyocd.yaml file. So I did that and got the following results:
pyocd_log.txt
Can you help me figure this out?

Sorry, I meant when I start the server with "pyocd gdb --target lpc1768" it keeps running.

Did you just ask the same question 6 times in 6 separate Issues? :nerd_face:

I got a "took too long to submit" error on each of them.
On Tue, Jul 20, 2021 at 10:21 AM Alfred Votolato @.***>
wrote:

I hope not. I did have a few submits that did not seem to go through
though.
On Tue, Jul 20, 2021 at 10:18 AM Tomasz CEDRO @.***>
wrote:

Did you just ask the same question 6 times in 6 separate Issues? 🤓
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pyocd/pyOCD/issues/1187#issuecomment-883431902, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOPRETAELPTW55HNT5BUEATTYWATJANCNFSM5AV3MCUQ
.

--
Alfred Votolato
Embedded Software Engineer
AndPlus
o: 508.425. 7533 m:<PHONE_NUMBER>
w: andplus.com e: @.***
Subscribe https://www.andplus.com/newsletter-signup to the AndPlus
newsletter

--
Alfred Votolato
Embedded Software Engineer
AndPlus
o: 508.425. 7533 m:<PHONE_NUMBER>
w: andplus.com e: @.***
Subscribe https://www.andplus.com/newsletter-signup to the AndPlus
newsletter

Closing as duplicate


Standardize README

Add apidoc to badges in banner header
Standardize headings in README

Codecov Report

Merging #143 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #143   +/-   ##
=======================================
  Coverage   84.32%   84.32%
=======================================
  Files          44       44
  Lines        3649     3649
=======================================
  Hits         3077     3077
  Misses        572      572

Flag
Coverage Δ

#SwiftKuery
84.32% <ø> (ø)
:arrow_up:

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 da013b3...c6cfd5e. Read the comment docs.


Tabs are not interpreded correctly ?

If y have the following code in my YAML file :
primary:	[section, key]  (the character between "primary:" and "[sec..." is a tab [\t])
then the array is not parsed and returned as string :
Array (     [0] => name:		i18n     [1] => table:		_i18n_site     [2] => primary:	[section, key]
But if i add a space before the tab, it works :
primary: 	[section, key]  (two characters between "primary:" and "[sec..." = a space followed by a tab [\t])
then it works :
Array (     [0] => name:		i18n     [1] => table:		_i18n_site     [primary] => Array         (             [0] => section             [1] => key         )
Both worked with spyc 0.5 but now with 0.6.2, it's not. Is there something I'm missing?

I found the way to fix the behaviour of 0.6.2 to match 0.5. In the function returnKeyValuePair, I replaced the ": " string by simply ":". It now explodes on ":", not ": ".
`
private function returnKeyValuePair ($line) {
$array = array();
$key = '';
if (strpos ($line, ':')) {
// It's a key/value pair most likely
// If the key is in double quotes pull it out
if (($line[0] == '"' || $line[0] == "'") && preg_match('/^("'"'*:)/',$line,$matches)) {
$value = trim(str_replace($matches[1],'',$line));
$key   = $matches[2];
} else {
// Do some guesswork as to the key and the value
$explode = explode(':', $line);
$key     = trim(array_shift($explode));
$value   = trim(implode(':', $explode));
$this->checkKeysInValue($value);
}
// Set the type of the value.  Int, string, etc
$value = $this->_toType($value);
  if ($key === '0') $key = '__!YAMLZero';
  $array[$key] = $value;
} else {
  $array = array ($line);
}
return $array;

}
`


python-consul:added support for AARCH64

added aarch64 compatible library of consul and made the necessary changes in build script
Signed-off-by: ossdev<EMAIL_ADDRESS>

Tests failed on travis due to unavailability of pypy as travis is not able to download pypy-5.3.1.tar.bz2 archive file.
This failure is not related to this PR.

Please can someone have a look at this PR.

Please can someone have a look at this PR.

Kindly look into this PR.


Move 20210722-yurtcluster-operator.md to docs/proposals

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage
/sig storage

What this PR does / why we need it:
move proposal file into correct folder.
Which issue(s) this PR fixes:

Fixes #328
Special notes for your reviewer:
/assign @rambohe-ch
Does this PR introduce a user-facing change?
NONE

other Note

sorry for any inconvenience.

/lgtm
/approve


Bring back dagger do?

Problem
The transition to a multi-language model has greatly improved the Dagger developer experience in many ways. But in its current form it has introduced a regression: there no longer is a standard way to discover and run pipelines from the CLI.

Dagger engine 0.2 (Europa)
Dagger engine 0.3 (Cloak)

Discover pipelines
dagger do --list
❌

Run a pipeline
dagger do <NAME>
❌

Solution
Overall design
The current plan is to implement API extensions, more specifically:

Ability to add custom pipelines (written in any language) to the graphql schema
Ability to introspect available pipelines from the schema
Ability to invoke these pipelines from the CLI without crafting a full graphql schema

The design for this is still in progress, and timing is uncertain for delivering it.
Short-term solution
This is issue is causing more pain and confusion than we originally expected. Yes developers love writing pipelines in their own language. But losing the convenience of a standard CLI entrypoint is a steep price to pay - especially in the context of CI integration.
Given the level of pain, and uncertainty on the timing of extensions, we should look for short-term solutions that don't compromise the long-term design. So far no design for such short-term solution has been proposed.

I think any solution here is going to have to involve one way or another deriving an API from source code. That will allow the targets and the args they accept to be known and exposed through the CLI.
From previous work on extensions, we already have that in Go+Python. NodeJS could be backfilled too.
The shortest path I see to getting something like this that doesn't compromise our longer term plans would be:

Backfill support for nodejs code-first schemas
Add the ability to derive a CLI interface from a graphql schema
Use that to implement dagger do

We can either automatically derive the runtime (i.e. the load+execute logic specific to each language) based on file extensions, add a flag that allows manual specification of the runtime, or something else

This would be missing the ability to easily invoke other extensions from your extension (and associated version control) and the ability to run "remote code" (i.e. an source code that's in git rather than local), which is why it's a smaller effort than "full blown extensions". I think if we're careful though work we put into this could all be setup for full blown extensions rather than throwaway though.

I think any solution here is going to have to involve one way or another deriving an API from source code. That will allow the targets and the args they accept to be known and exposed through the CLI.

One possible shortcut would be to ship a dagger.json file that can be produced and consumed in a useful way now, before extensions existed, and can be migrated in a reasonable way once extensions exist.
I think it could be as simple as a:
// Dagger project file schema
name?: string
description?: string
// All types to be deprecated post-extensions, except "graphql"
type: "go"|"python"|"javascript"|"typescript"|"exec"|"graphql"
// Path of executable entrypoint, relative to project directory
// Only required for project type "exec"
entrypoint?: string

Then dagger do would use this file to list & invoke pipelines.

One possible shortcut would be to ship a dagger.json file that can be produced and consumed in a useful way now, before extensions existed, and can be migrated in a reasonable way once extensions exist.

I'm missing some pieces here. For a concrete example, say I wrote some go code like this:
func Echo(input string) string {
  return input
}

func Yell(input string) string {
  return input + "!!!!!"
}

How would I invoke the targets using dagger.json and dagger do without dagger doing some magic to derive an API from that source code?

One possible shortcut would be to ship a dagger.json file that can be produced and consumed in a useful way now, before extensions existed, and can be migrated in a reasonable way once extensions exist.

I'm missing some pieces here. For a concrete example, say I wrote some go code like this:
func Echo(input string) string {
  return input
}

func Yell(input string) string {
  return input + "!!!!!"
}

How would I invoke the targets using dagger.json and dagger do without dagger doing some magic to derive an API from that source code?

I'm picturing a very simple convention with less magic than you imagine:

Developer must write a standalone program (the entrypoint), and write it to...

main.go for type: "go"
index.js for type: "js"
index.ts for type: "ts"
main.py for type: "python"
<value of entrypoint field> for type: "exec"

dagger do invokes the pipeline by executing the entrypoint, and passing the pipeline name as argument

Developer must write a standalone program (the entrypoint), and write it to...

I see, so for go, users would be responsible for writing a main func that actually invokes targets based on a command line arg, right? If we implemented this, documented it for users and then they asked what the benefits of using dagger do over just writing the same main func and invoking it directly with go run are, what would our answer be? It seems like unless we add some kind of sugar it just becomes mostly boilerplate around the same interface you get from go run.

Developer must write a standalone program (the entrypoint), and write it to...

I see, so for go, users would be responsible for writing a main func that actually invokes targets based on a command line arg, right? If we implemented this, documented it for users and then they asked what the benefits of using dagger do over just writing the same main func and invoking it directly with go run are, what would our answer be? It seems like unless we add some kind of sugar it just becomes mostly boilerplate around the same interface you get from go run.

Disclaimer: I'm just exploring this idea, so it may not actually solve anything. With that said...
The benefit would be a standardized entrypoint, which in turn would mean a (more) standardized way of invoking Dagger from CI.
The motivation for this issue is users reporting that they are generally confused as to how they're supposed to use Dagger, and how it maps in their familiar CI experience.
Example on Discord today from @sw360cab:

Hi guys. Long time I am not joining here... I am stunned by all the updates/changes that are going on.
I started playing with Go SDK and I was wondering if there is a final goal to ever reach Dagger Cue SDK (formerly Dagger CLI), if it makes sense.
I mean Dagger Cue SDK is really able to create portable Plans and to make them available throughout the various/major CI/CD providers. Will be something like that possible through Go SDK in the future or they are intended to remain separate entities with a different purpose?

So how can I make a comparison between what I currently can achieve with Dagger CUE plan + Dagger Cue CLI installed on CI/CD provider (e.g. Github Actions) and what I can write down using an SDK (e.g. GO)?
Because right now I was able to replicate my Plan in the SDK but I am struggling understanding what I can do with that, compared to how powerful is porting my plan to any CI/CD provider by just installing the Dagger CUE client into.
I hope it make sense what I am writing, Maybe I am mixing up concepts and just doing confusion and noise 😵💫

I felt a little bit lost, trying to connect the dots.

Reading this thread something popped in my head that I think shouldn't go unnoticed. If we bring back dagger do to improve the DX for discovering and running pipelines, we should be mindful about what other aspects of the DX we're hurting because of this.
For example:

Writing boilerplate code so the CLI can discover and run pipelines.
Confusion between different pipeline entry-points. Some users might use dagger do, others go run for convenience because they don't want to install the CLI for example
Adding an extra step to the CI setup pipeline to download the CLI

At this stage I'm not sure if there's something we could do that provides "the best" experience until we have the API extensions. Do you think this could be temporarily mitigated by improving our docs?

Writing boilerplate code so the CLI can discover and run pipelines.

This will be true with extensions.

Confusion between different pipeline entry-points. Some users might use dagger do, others go run for convenience because they don't want to install the CLI for example

This will also be true with extensions.

Adding an extra step to the CI setup pipeline to download the CLI

We should already recommend this, so you can configure your session with dagger run.

At this stage I'm not sure if there's something we could do that provides "the best" experience until we have the API extensions. Do you think this could be temporarily mitigated by improving our docs?

I don't want to dismiss your concerns - I'm not even sure this particular design is a good idea. BUT I am beginning to worry that "the extensions will do this" is becoming an excuse to ignore the problem completely. "The extensions" are not going to design themselves, we need to keep the design process alive, and attempts at incremental improvements like this one are part of that.

BUT I am beginning to worry that "the extensions will do this" is becoming an excuse to ignore the problem completely.

I totally understand your feelings and I'm not against of shipping something intermediate that can alleviate users pain while bringing us a bit closer to the final solution. Having said that, the main benefit of API extensions is that it absorbs the complexity of having to configure the SDK runtime, since that'll be provided by the engine. In my head, with extensions there's a clear API separation between the CLI (loader) and the pipeline code itself. Users will only need to install the dagger CLI and everything else will be automatically configured for them.
It'd be nice if we can find an intermediate solution somehow that could bring us closer to that final experience. For example, is there something we can do in the engine so all SDK runtimes are provided to the user as containers and then dagger do somehow uses that without needing the runtime to be installed locally?  I know I'm not proposing anyting about how users will define and call their pipelines, but I mostly wanted to highlight the opportunity to start simplifying the runtime setup to the user as it'll happen with Extensions.
Maybe the previous paragraph could be an improvement over your initial proposal Solomon. Keep a dagger.json (or similar) descriptor, but also enable the engine to be able to bootstrap the pipeline language runtime and start it. I'm not sure if this is what you had in mind in your initial post, my interpretation was that the runtime would still have to be present in the local machine where dagger do is triggered.

This would help make Dagger more understandable to users that are familiar with the "normal" way of doing CI, and are put off by the current situation. The motivation for this issue is users reporting that they are generally confused as to how they're supposed to use Dagger, and how it maps in their familiar CI experience.

Yeah that makes sense. I think if we pursue something like this it'd be best to really optimize for low boilerplate. The benefits of this first step are real but marginal, so even a small bit of extra overhead can make it overall not worth it IMO.
That makes me feel like this would be worth it if we could avoid dagger.json. Along those lines, thinking out loud:

What if instead of adding dagger do we add an extra feature to dagger run that enables you to do e.g. dagger run ./main.go, or, if you are in a nodejs project, dagger run test where test is a script in package.json.
This would require a lot of autodetection magic; probably too much honestly since it would be hard to distinguish between running a command called test and a package.json script called test.
I suppose we could add a flag like dagger run --sdk nodejs test but at that point why not just have users call dagger run yarn test

So yeah, I'm not sure if I see a path that makes this worth it yet. It's a choice between excessive boilerplate or excessive magic (the bad+confusing kind, not the delightful kind). But maybe there's a middle ground I'm not seeing yet.

I agree that docs might be the best short term option here; can just show commands like dagger run go run ... and dagger run yarn ....
There is a grain of optimism in me that re-using the extension code-first schema support to expose a pipeline API via command line args might be easier than it sounds, mostly just because the hardest part of that work is already out of the way for go+python at least. If there's time in the near future to experiment a bit I may give it a shot (or anyone else should feel free to also)

There is a grain of optimism in me that re-using the extension code-first schema support to expose a pipeline API via command line args might be easier than it sounds,

This would be a possible alternative to the "bring us closer to the final implementation" idea I was trying to transmit in my previous post.

This makes me want to hold off on un-hiding dagger run, to keep the door open to a better abstraction that combines dagger do and dagger run in a way that improves the experience today, and is forward-compatible with extensions.

Users will only need to install the dagger CLI and everything else will be automatically configured for them.
It'd be nice if we can find an intermediate solution somehow that could bring us closer to that final experience.

Isn't that what we're discussing now? What does this "final experience" look like exactly from the command-line? We haven't actually defined that. Our extensions design so far defines 1) how to package pipeline logic into graphql resolvers that the engine can load and run; 2) how to invoke it from a graphql query. It doesn't define how end users will experience this from the CLI. So why not start defining it now?
Options I see so far:

Send GraphQL queries directly: dagger query
Execute a client tool directly: CLI experience undefined (depends on the tool)
Execute a client tool via dagger run: CLI experience partially undefined (arguments to dagger run depend on the tool)
Execute dagger do STEP [...STEP] where each STEP maps to a graphql query

My point I suppose, is that the problem of standardizing the CLI experience is related to extensions, but orthogonal. We have this problem now (sooner and stronger than I expected), and we will continue to have it with extensions. When we say "extensions will solve this" that's not technically true, what we're really saying is "why worry about this until we have extensions". The answer as it turns out is: "because users are confused about a lack of standardized CLI experience today".

is there something we can do in the engine so all SDK runtimes are provided to the user as containers and then dagger do somehow uses that without needing the runtime to be installed locally? I know I'm not proposing anyting about how users will define and call their pipelines, but I mostly wanted to highlight the opportunity to start simplifying the runtime setup to the user as it'll happen with Extensions.

That would be nice, and definitely an additional OX improvement compared to what I proposed (no runtime dependencies on Go, NodeJS etc!), but it's a breaking change for the DX: right now your client tool has full access to the host, but that's no longer the case if we run it in a container. This breaking change is inevitable with extensions, but since it's something new and exciting, it's a good tradeoff. Different story if we break the behavior of your client tools without giving you any DX improvement in return..

This breaking change is inevitable with extensions, but since it's something new and exciting, it's a good tradeoff. Different story if we break the behavior of your client tools without giving you any DX improvement in return..

Agree with your points about being a breaking change for DX and the Extensions particularity.

My point I suppose, is that the problem of standardizing the CLI experience is related to extensions, but orthogonal. We have this problem now (sooner and stronger than I expected), and we will continue to have it with extensions. When we say "extensions will solve this" that's not technically true, what we're really saying is "why worry about this until we have extensions". The answer as it turns out is: "because users are confused about a lack of standardized CLI experience today".

I also agree with this but, is it really something we can do something better? The fact that dagger is designed to be used primarily as an SDK is a core and intended decision, and trying to come up with a CLI as some sort of "universal loader/runner" across all languages seems like something that doesn't fit in the original design which we're trying to force. This reminds me to the same thing that happened with containers when people tried to put fully bloated init systems and tried to use them as "lightweight VM's" (besides the fact that some people currently do it).
Would it hurt to start with better docs explaining the reason for this and then referencing how to setup CI pipeline using standard loaders for each language? (I think we have this examples today). Given the ideas that we have discussed so far, it doesn't seem to me that they are improving the overall DX and I'm running out of ideas. I'll keep a thread in my head for this.

Yes, I'm with @marcosnils generally I think. Speaking for Python here, there's many ways to run a python script. If there would be a unified entrypoint, to me it would be running in a container, but you lose direct access to host for example.
I also have some use cases in mind for Dagger that are not running from the terminal. So the simplicity of running a python script is good enough for me. Python CI pipelines already setup a Python environment usually. We just make that simpler. Still nice to "document" what we think is a good solution for declaring pipeline steps (like lint and test). Either with conveniences from the SDK for less boilerplate, or just a guide.
You have a nice chainable API you can use, but it's not required. You could ditch the whole SDK, run dagger listen manually and use an entirely different GraphQL library, or raw query strings. Same thing with running from the terminal experience vs some other environment.
But there's different package managers, different python interpreters or even their name. So it's hard to see how this can be implemented in a simple way. Seems like added complexity that's not worth it.
Some of the confusion users are having may come from the previous version of Dagger where you ran .cue pipelines with the CLI. We just need to have clear documentation on this.

I'm going to take a step back here. Forget about dagger do or any hypothetical future design: I think there's confusion about the current design and the fact that it already defines a standardized CLI entrypoint: dagger run.
If you're asking "what would be the point of a standardized CLI entrypoint" I'm sorry to say that that ship has sailed: we already have one and will be relying on it more and more in the context of CI integration, because that is how we will offer the best OX. The only question is: should we do this with dagger run as designed currently, or can we further improve the experience with a higher-level dagger do? Not having a standardized CLI entrypoint at all, or keeping it as an exception instead of the recommended way to run things, is not an option.

Let me rephrase.
You can run today dagger run python script.py while not even using/importing the Python SDK.
The same way it's opt-in and gives you some conveniences for a nicer script.py (as opposed do doing raw queries), the SDK could also support an opinionated way to declare "steps" that can be detected by dagger do.
It's just another convenience layer, I'm ok with that.

If I may add a few comments from a user's perspective:
Most of my projects already have a Makefile or a Taskfile.yaml or something that acts a task runner for the project. (Despite how nice and easy go build and go test are they are just not good enough for all around everyday use)
I most certainly will continue having those tools around for development anyway. I can easily integrate my Dagger execution into them.
I'd much rather do that compared to using a temporary, short-term solution that may change significantly. I'm (and my peers are) already familiar with our current toolings, so integrating Dagger into those is potentially an even better way to introduce a new tool to the chain.
I'll also say that not having to download a CLI felt good. Even though I use Nix a lot (I had a bunch of practices to download CLI tools (eg. from Makefiles) even before that), not having to download a new CLI every other week to get the new features made upgrading to the Go SDK easier a lot.
It seems to me that this is mostly a problem for users who want to use Dagger. I don't want to use Dagger, I want to run CI. That fact that it's Dagger under the hood is great, but I actually don't mind that people don't know/care what it is.
Obviously, someone has to write those pipelines, but once I'm working on that, I already know enough about Dagger to either use go run (and I don't really need discovery) or just run Dagger through my usual task runners (eg. make ci).
I don't want to diminish anyone's pain who feels the need for a CLI, I just wanted to say there are alternatives and I'll probably prefer sticking to those over a temporary solution.

To offer some ideas as well: I wonder if the SDKs could offer a way to provide insights into pipelines to the Dagger CLI. Thinking about the d2 graph we saw in the community call yesterday. I know those are generated from logs, but the information is still there, I'm just not sure how to extract it (eg. passing a dummy client to pipeline code that doesn't actually run anything just traces the different calls and builds the graph).

This has been solved with the introduction of Dagger Functions, and dagger call :)


Class extends value undefined is not a constructor or null

Environment

Operating System: Linux
Node Version:     v16.20.1
Nuxt Version:     3.6.5
Nitro Version:    2.5.2
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      ssr, spaLoadingTemplate, app, css, modules, gtag, googleFonts
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction

I Install the google-auth-library in nuxtjs 3 with vite
then i make the separate helper call spreadsheet.ts for calling the method when i need it
this my inside spreadsheet.ts

then i import spreadsheet.ts in another file to hit the method & i got the error like this

and also on error preview in browser

at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:4899:36)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5104:24)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5223:31)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5521:20)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:7525:20)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)

this the link https://stackblitz.com/edit/github-mxmr67?file=pages%2Findex.vue
Describe the bug
its error from the bundler or error from vite or maybe the package ?, if the error is from vite can you give me a suggest about the vite config ? to solve this
i try to fix from this issue but still not fix
also i report this to google-auth-library for making sure 1632

this my stackblitz reproduction

any idea for this issue ? or maybe the suggest ?

Same issue for me

@danielroe

any update for this issue ? @danielroe

I have catched a similar situation and tried searching, but it seems there hasn't been any update on this issue. It appears that the google-auth-library is not compatible with the client, and with Nuxt 3, it works on the server. Therefore, you can handle it in plugins with server customization or create an API in the server folder and use it.
Hope this helps someone experiencing this issue.

Thanks for updating. I think we should probably close this here then.

Environment

Operating System: Linux
Node Version:     v16.20.1
Nuxt Version:     3.6.5
Nitro Version:    2.5.2
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      ssr, spaLoadingTemplate, app, css, modules, gtag, googleFonts
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction

I Install the google-auth-library in nuxtjs 3 with vite
then i make the separate helper call spreadsheet.ts for calling the method when i need it
this my inside spreadsheet.ts

then i import spreadsheet.ts in another file to hit the method & i got the error like this

and also on error preview in browser

at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:4899:36)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5104:24)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5223:31)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:5521:20)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)
at<EMAIL_ADDRESS>(http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/google-auth-library.js?v=6e413f2f:7525:20)
at __require (http://localhost:3000/_sastrala-member/node_modules/.cache/vite/client/deps/chunk-DFKQJ226.js?v=35cede96:8:50)

this the link https://stackblitz.com/edit/github-mxmr67?file=pages%2Findex.vue
Describe the bug
its error from the bundler or error from vite or maybe the package ?, if the error is from vite can you give me a suggest about the vite config ? to solve this
i try to fix from this issue but still not fix
also i report this to google-auth-library for making sure 1632

i am also getting same error in nuxt, when i am getting data from my composables to my components.

Eu estou com mesmo problema quando tentei usar, intalei a blibloteca "google-auth-library" e "google-spreadsheet" e coloquei os dados e quando o app inicializa exibe essa mensagem:
google-auth-library.js?v=629557de:1157 Uncaught (in promise) TypeError: Class extends value undefined is not a constructor or null
Meu codigo:
import google from<EMAIL_ADDRESS>import { JWT } from "google-auth-library";
import { GoogleSpreadsheet } from "google-spreadsheet";

    try {
      const serviceAccountAuth = new JWT({
        email: google.client_email,
        key: google.private_key,
        scopes: [
          "https://www.googleapis.com/auth/spreadsheets",
        ],
      });
    } catch (error) {
      console.log("Error ------------------");
      console.log(error);
    }

    const doc = new GoogleSpreadsheet("<the sheet ID from the url>", serviceAccountAuth);

I have catched a similar situation and tried searching, but it seems there hasn't been any update on this issue. It appears that the google-auth-library is not compatible with the client, and with Nuxt 3, it works on the server. Therefore, you can handle it in plugins with server customization or create an API in the server folder and use it.
Hope this helps someone experiencing this issue.

Could you please provide more details regarding your mention?

Is it the issue caused by the (google-auth-library) library still uses the require while others (e.g., @googleapis/sheets v4 or a vuejs component) depend on it have been changed to use the import for modules loading?
Uncaught (in promise) TypeError: Class extends value undefined is not a constructor or null
at node_modules/google-auth-library/build/src/auth/authclient.js (authclient.js:31:35)
at __require (chunk-WMTNK64S.js?v=40045171:15:50)
at node_modules/google-auth-library/build/src/auth/oauth2client.js (oauth2client.js:22:22)
at __require (chunk-WMTNK64S.js?v=40045171:15:50)
at node_modules/google-auth-library/build/src/auth/computeclient.js (computeclient.js:19:24)
at __require (chunk-WMTNK64S.js?v=40045171:15:50)
at node_modules/google-auth-library/build/src/auth/googleauth.js (googleauth.js:36:25)
at __require (chunk-WMTNK64S.js?v=40045171:15:50)
at node_modules/google-auth-library/build/src/index.js (index.js:17:22)
at __require (chunk-WMTNK64S.js?v=40045171:15:50)


[FLINK-15265] Remove "-executor" suffix from executor names

The executor names always have "-executor" as a suffix, this is
reduntant. Currently, the executor name is also used to retrieve a
ClusterClient, where it is unfortunate that the name has executor as a
suffix. In the future we might provide something like a FlinkClient that
offers a programmatic API for the functionality of bin/flink, here we
would also use the same names.
In reality, the "executor names" are not names of executors but
deployment targets. That's why the current naming seems a bit unnatural.
This is a simple search-and-replace job, no new functionality. So no tests are needed.

@flinkbot run azure

@flinkbot run travis

@aljoscha @kl0u Do you think we need to unify the executor name. I think it is better we have a consistent executor name schema before it replace the -m cli option. Currently, we have the following names.

YarnSessionClusterExecutor -> yarn-session-executor
YarnJobClusterExecutor -> yarn-per-job-executor
KubernetesSessionClusterExecutor -> kubernetes-session-cluster
KubernetesJobClusterExecutor -> kubernetes-job-cluster (TODO)

It will be very good to remove the suffix and unify the name of executor.
LGTM, +1 for merging.


grt: fix gridsize calculation if diesize is smaller than tilesize

GRT: Make sure that the grid size is at least 1 by 1.
With small designs the tile size could be larger than the width or height of the die area, for example in a single row macro.

@TheMightyDuckOfDoom Thanks for your contribution! Could you add a unit test for this case?

I added a regression test.
Without the fix it fails as expected, while with the fix it should work.

I missed to add a .ok file for the regression test, but have added it now.

I added a regression test.
Without the fix it fails as expected, while with the fix it should work.

Extra credit for a nice, concise test case 👏


Update quasiquotes.md

a " was missing in the 'new' quasiquote

Hi, thanks for the contribution! Would you mind signing the Scala CLA, so that I can merge? https://www.typesafe.com/contribute/cla/scala

Thanks!


Fixed title

i simply inserted one space and fixed it's title.

Hi,
this is also been fixed by #329.

ok, sorry, i closed this.

nah, don't close it. Maybe something is wrong with my pr, so yours can be merged earlier than mine.

ok i opened it

I think that both PRs will be merged together and the correction will apply anyway.


Use names for children of sprites

Currently it just uses their original location pre-compilation to identify the child images within each sprite. This is a bit messy, and it would be better if instead each child image was given a name during compilation.

There are no sprites any more, so this issue is no longer relevant.


Process multiples input lines

Hi,
Thank's for sharing this tool.
Adding below few ideas/feature requests. As they are quite "close" and/or linked to each other (I think), I list those in a single "issue".
It would be nice to have an option for "direct" results without extra informations lines and/or that even could be the default ouput and the current output with some kind of -interactive
$ usl 'https://emea01.safelinks.protection.outlook.com/?url=http%xxxxxxxxx'
example.net

Current output could also be
$ usl -interactive

Enter URL: https://emea01.safelinks.protection.outlook.com/?url=http%xxxxx
Original URL: http://example.net

It would be nice to be able to be able to bulk process multiple links at once in parallel

From piped data

$ cat file.with.links | usl
http://example.com
http://example.net

From input file

$ usl -inputfile file.with.links
http://example.com
http://example.net

Overall I like the ideas, but I'd like to keep the current behavior of prompting the user if no input is provided. When I had others test the tool this behavior seemed intuitive to them and did not require further explanation.
Based on that, I think this would be the result:

retain interactive prompt if no input given
emit results without leading explanation text (i.e., drop Original URL: text and following newline)
if input given, process and emit results without decoration until no further input provided (e.g., via pipe)
if input file given, process the same way as stdin

As I mentioned I have other items ahead of this, so would probably work on this in pieces.

@uggyuggy Dev build available here:

https://github.com/atc0005/safelinks/releases/tag/v0.3.0-alpha.1

No doc updates yet, but hopefully the help text covers new behavior well enough.

No doc updates yet, but hopefully the help text covers new behavior well enough.

Updated README coverage:

https://github.com/atc0005/safelinks/blob/v0.3.0-alpha.3/README.md

Changes included in v0.3.0 release:

https://github.com/atc0005/safelinks/releases/tag/v0.3.0

Hi @atc0005
Tested it, looks great.
Thank's  👍


Cluster node hosted via embedded can't find address of the application

Hi,
I ran into some issue while configuring Kestrel through the application config file using the server.urls parameter.
If the StartUp class takes longer than RaftHttCluster to start, it cannot find the server address and the application stops with the message:
g:\work\VSNET\github\dotNext\src\examples\RaftNode\bin\Debug\netcoreapp3.1>RaftNode.exe http 3262
Unhandled exception. DotNext.Net.Cluster.Consensus.Raft.RaftProtocolException: Configured list of members in cluster doesn't contain address of entire application
   at DotNext.Net.Cluster.Consensus.Raft.Http.RaftHttpCluster.StartAsync(CancellationToken token) in g:\work\VSNET\github\dotNext\src\cluster\DotNext.AspNetCore.Cluster\Net\Cluster\Consensus\Raft\Http\RaftHttpCluster.cs:line 138
   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
   at RaftNode.Program.Main(String[] args) in g:\work\VSNET\github\dotNext\src\examples\RaftNode\Program.cs:line 143
   at RaftNode.Program.<Main>(String[] args)

I think this is related to the issue https://github.com/aspnet/Hosting/issues/1390 which says that server.Features.Get<IServerAddresses>() gets populated after StartUp is done.
It's easy to reproduce:

add the parameter to the configuration dictionary {"server.urls", "http: // localhost: 3262"}
configure Kestrel without specifying the port UseKestrel()
add a delay at the end of the Startup.ConfigureServices (..) method System.Threading.Thread.Sleep (10000)
compile and run the application with http protocol

The only workaround is setting up a Kestrel listener address and port while building the host, isn't it?

@Eykhler , the current solution is not elegant, correct. However, it's working for most scenarios. Probably, it's time to return back and fix it. aspnet/Hosting#1390 is one of the show stoppers. However, the issue contains a hint: if IHostedService depends on IServer instance then IServerAddresses should be available at the time of StartAsync. RaftHttpCluster implements exactly in the same way. But now I'm looking at your issue and can conclude that such an approach is not working for some reason.
What can I offer here:

Wait for IServerAddresses in a loop inside of RaftHttpCluster.StartAsync. Not elegant, because IServerAddresses may be unavailableall the time. IDK, is there any startup timeout in generic host? If no, the app may freeze infinitely.
Examine configuration and use server.urls if IServerAddresses is unavailable. This approach is not good, because embedded mode uses underlying HTTP server (IServer instance) which may differs from Kestrel and server.urls configuration property can be ignored by it.

@Eykhler , I was unable to reproduce you issue. Delay in ConfigureServices just delays execution of RaftHttpCluster.StartAsync method. Kestrel is always started at that point and provided IServerAddresses is correct. server.urls is ignored by Kestrel. By default, it uses two addresses:

http://localhost:5000
http://localhost:5001

Here is my modified UseAspNetCoreHost method from RaftNode example:
 var configuration = new Dictionary<string, string>
            {
                {"partitioning", "false"},
                {"lowerElectionTimeout", "150" },
                {"upperElectionTimeout", "300" },
                {"server.urls", "http://localhost:3265"},
                {"members:0", "https://localhost:3262"},
                {"members:1", "https://localhost:3263"},
                {"members:2", "https://localhost:3264"},
                {"requestJournal:memoryLimit", "5" },
                {"requestJournal:expiration", "00:01:00" }
            };
            if (!string.IsNullOrEmpty(persistentStorage))
                configuration[SimplePersistentState.LogLocation] = persistentStorage;
            return new HostBuilder().ConfigureWebHost(webHost =>
            {
                webHost.UseKestrel()
                // .UseKestrel(options =>
                // {
                //     options.ListenLocalhost(port, listener => listener.UseHttps(LoadCertificate()));
                // })
                .UseStartup<Startup>();
            })
            .ConfigureLogging(builder => builder.AddConsole().SetMinimumLevel(LogLevel.Error))
            .ConfigureAppConfiguration(builder => builder.AddInMemoryCollection(configuration))
            .JoinCluster()
            .Build()
            .RunAsync();

It means that trick with IHostedService is working and IServer always in started state when RaftHttpCluster.StartAsync called.

Thanks for the clarification!
Now I am setting up the Kestrel listener during host build, this is not a problem for me.
The main disadvantage is that it works fine under the debugger, but when running without a debugger connected, it crashes, and only examining the source code allows you to understand the real problem.
Maybe you can use IHostLifetime.WaitForStartAsync(CancellationToken) method at the start of the RaftHttpCluster to delay start (it's maybe configured).
Maybe highlight this point in the documentation to save time for other developers!?

WaitForStartAsync will be recursive call, because it waits for all IHostedServices. Could you please provide source code of modified UseAspNetCoreHost method?

If you're using UseKestrel method without parameters as shown above then Kestrel doesn't know anything about server.urls configuration parameter and just ignore it. Instead, it uses two endpoins by default which are not in the list of members. Therefore, you get this exception.

Yes you are right, Kestrel doesn't know about the server.urls parameter, my example is not up to date.
I will try to modify the example using a config file and reproduce the error.

You can reproduce it using in-memory configuration instead of file. It's transparent for Kestrel and other ASP.NET Core components.

Sorry, I can't reproduce the issue with RaftNode example project right now.
But in my project, I see the following console output:
dbug: Aurus.CmsPlus.Backend.Service.Startup[0]
      Startup completed
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://<IP_ADDRESS>:6000

the URL http://<IP_ADDRESS>:6000 is the value of the server.urls configuration parameter, and the Startup completed is the last line of the Startup.Configure() method. So the Kestrel listener URL is replaced after Startup.

Startup completed log message is in Startup class. Its configuration methods are called by Host synchronously. But RaftHttpCluster.StartAsync is not calling by Startup class. It's called afterwards by constructed Host as well as IServer.
Message Now listening on: http://<IP_ADDRESS>:6000 is produced by GenericWebHostService inside of StartAsync method. As a result, HTTP server is always started and initialized before RaftHttpCluster.StartAsync is called.
You can check this with the following:

Write you own hosted service (derived from BackgroundService or implements IHostedService directly)
Inject IServer via constructor and save it to the field
Prints IServerAddresses in your implementation of StartAsync method

At the moment, I cannot confirm this issue as a bug. So I'm closing it.


Q: Passing CMake variables on the command line

First of all: thanks for this very useful tool.
I was wondering whether it is a concsious decision (or result of a decision made in Python build flow) to only allow passing CMake overriding settings via a toml file (via -C--local=...). Oftentimes, CMake variables need to be set due to environment conditions such as the toolchain used, installation location of libraries, etc. It is a bit cumbersome to always have to create toml files for one-time passing of such settings.
It gets particularly tricky if there is a combination of different kinds of settings that we may already have separate tomls for: e.g. combining settings for finding libraries/compilers with settings such as the build type (Debug/Release/...).

No particular reason, other than the limited development time available :) up to now, other features have simply taken precedence.
I agree that it should eventually be supported, but I intend to refactor the current configuration file parser first. Currently, it lacks a good strategy to combine options from different sources: e.g. when combining a CMake -D option that is actually a list (e.g. CMAKE_PREFIX_PATH), right now it only keeps the value from the source that was added last, whereas it would make more sense to merge the different lists.
For example, Conan allows you to explicitly specify how to merge options, but this is not something that TOML supports. Adding support for this would require switching to a different (or alternative) file format for local files, and would require writing a command-line parser that can deal with the configuration tree data structure.
In the short term, I think adding a -D flag (to set CMake variables from the command line) would definitely be a possibility, albeit rather limited.

To make the lack of command-line options slightly more bearable, I usually use a Bash heredoc. For example:
cat > ninja-debug-release.cross.toml <<- EOF
[cmake]
config = ["Debug", "Release"]
generator = "Ninja Multi-Config"
[cmake.options]
CMAKE_FIND_ROOT_PATH = "$staging/pybind11;$staging/eigen-master;$staging/casadi"
USE_GLOBAL_PYBIND11 = "On"
ALPAQA_WITH_CUTEST = "On"
EOF
python -m build -w . \
    -C--cross="$PWD/ninja-debug-release.cross.toml" \
    -C--cross="$staging/$host.py-build-cmake.cross.toml"

Some options can also be passed to CMake using environment variables (https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html).
Another possibility is to use CMake presets (https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html), where you define the options you need, and then simply pass that preset to py-build-cmake. It does require configuration files, though.

Thanks for the explanation. A heredoc is a good solution for now! If it's OK with you, I'll leave the issue open for future reference.


Viewer

Is it possible to replace surfer2 with xeokit-bim-viewer-app? It's just that there are no tools for work in surfer2, for example, cross-section or measurement.

or on gemini-viewer it also uses GIF format, only there are no matadany

Another candidate is bimsurfer v3 https://github.com/opensourceBIM/BIMsurfer/ it also has sections and measurement functionality.
I'm not entirely sure about the effort to support xeokit, but I would not immediately see this in scope of our version ifc-pipeline. We have to review license differences also, not sure about MIT + AGPL. If you want to work on it, I can see if I can provide advise where needed. At least the IfcConvert bit is shared I think.
Another alternative would be that you keep ifc-pipeline as is and build your own web-based front-end around xeokit that uses the converted glTF from ifc-pipeline. Not sure if xeokit needs their own format or that it can also load relatively well from the .glb that IfcConvert provides directly.

There is no complete grouping of objects by category in the selection tree. How to solve it

?

There is no grouping by category, it's only by containment. The walls and furniture you highlighted are all contained in building storey "Nivel 1".


Cmake misc fixes

Use known best practices and apply some coding style.

This pull request is now managed with CodeReviewHub. Refresh.

@krocard @tcahuzax please review

:+1:

:shipit:


New version: AILight.AILZ80ASM version 1.0.12

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest --manifest .\manifest\a\AILight\AILZ80ASM\1.0.12?
[ ] Have you tested your manifest locally with winget install --manifest .\manifest\a\AILight\AILZ80ASM\1.0.12?
[ ] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Manual Validation ended with:

This might be a false positive. We can rescan tomorrow.

@stephengillie Cloud you merge?
relation #124353 #123673


Initialize a monitor object w/ a given code

In addition to creating a monitor from scratch using an API token & options, we should be able to supply a Cronitor code and use a pre-existing monitor.

Closed by v0.3.0


Transactional Producers, Akka 2.5.3, Kafka 1.0

All is in the title

Hi Olivier,
Thank you for your analyze.

I was thinking that i could use no transactional producer for the case of 1 event to persist. But i will not do that. So i could use read_comitted. You're right.
I think you're wrong by thinking that writers actors could help. If i remember, for a given persistence id, you always use the same producer (via the modulo operation). See code below in your request:
private def writerFor(persistenceId: String): ActorRef =		    private def writerFor(persistenceId: String): ActorRef =
writers(math.abs(persistenceId.hashCode) % config.writeConcurrency)
It helps only if you have a lot persistent actors. I don't think it's a good idea to have a lot of topics in kafka, so it does not make sense for me. If you have only one persisted actor in your jvm, you will use always the same transaction/producer. You could have 8 writers, only one will be used.
And initially the writers was used because the old producer was synchronous.

Tell me if i make a mistake. Could you please benchmark the 2 solutions to have an idea of the perdormance loss and how i can execute it here ?

You are right in that this won't increase throughput in the case of a single persistent entity. I'm not sure if the throughput test in  the tck uses a single persistent entity. But in a real world case, there will be a lot more than eight persistent actors, so the throughput will benefit a lot from multiple producers.
If you think about it, the producer in this pull request is still blocking, since commit transaction is blocking. So it makes sense we should keep the multiple writers.
With regard to running many persistent actors on Kafka resulting in a lot of topics being created, we could explore decoupling the number of topics from the number of actors by storing multiple actor journals in a single topic and filtering them when replaying. This is a separate issue however, and not as high of a priority IMO.

The throughput on persist (not persistAsync) is tested (optionally but it figures in the TCK)  with only one persistent Actor. So all the persist message passing will be serialized into your single actor that manages this persistent actor. And each event will produce a begin/send one message/commit cycle. There's no doubt. But you're right, it makes sense to conserve the writer since commit is blocking.
In my pull request, i do best effort to discard the old API and the zookeeper calls. In yours, I see that you are still using zookeeper to complete the broker set. The Producer API already does that. Why do you keep it? I discard the embedded test broker code since it already exists in the kafka project. To not reinvent the wheel. We cannot keep on mixing old/obsolete code and the new one.
Respecting this last point, we could combine both pull requests.

We're looking to leverage Kafka as an event journal for Akka, and would love to use this - any chance this PR could get merged?

@krasserm ? :)

@krasserm Let's go for a merge or a review?

I close this pull request. Krasserm seems to be too busy to take a look. The fork is right here : https://github.com/worldline-messaging/akka-persistence-kafka and it will be improved regularly


The type initializer for 'System.Text.Json.JsonSerializer' threw an exception

Trying to get the Xamarin Forms iOS application running but get a serialization error when I press the Sync button in the sample provided here on GitHub.
I am compiling this on the most recent version of Visual Studio 2019 on Mac (8.10.14 (build 17)).  It's possible this may be caused by an issue with System.Text.Json but I have spent 2 days trying ways to work around that...to no avail.   (I've even tried converting Nube* from System.Text.Json to Newtonsoft--but ultimately that rabbit hole lead to other issues.)
Even though I'm using the sample I'm still going to add the solution that I'm reproducing this with.  My "offline.db" file has a single ToDo item in it (got there by me clicking the "Add Item" button in the sample)
Please help me get this running on iOS.  I'm really excited about using this but I can't get it working it.

samples.zip
StackTrace.txt
offline.db.zip

Hi, thx for the detailed report.
The problem seems to be the "MissingMethodException" within the TypeInitializationException.
Following the accepted answer from https://docs.microsoft.com/en-us/answers/questions/302548/jsonserializer-throws-exception-in-xamarinios.html did fix it for me.

Right click the NubeSync.Mobile.iOS project and select Edit Project File
Add this at the end before the </Project> Tag and you should be fine:

  <ItemGroup>
    <PackageReference Include="System.Memory" Version="4.5.4">
    <IncludeAssets>none</IncludeAssets>
    </PackageReference>
    <PackageReference Include="System.Buffers" Version="4.5.1">
    <IncludeAssets>none</IncludeAssets>
    </PackageReference>
  </ItemGroup>

I will have to add that to the samples though.

Thank you!  I (thought I) had tried that but apparently I didn’t do something correctly.  Tried again as you described and it seems to be working now.  Thanks again…fingers crossed everything goes well from here.
I truly appreciate the timely response!
Cheers!


Source images

Find or create suitable images to illustrate each of the player activities. See #2 for details.

Images linking to tasks added to Images folder


new features  are separate from the real problem list, which is better.

New Feature

[x] Item 1
[ ] Item 2
[ ] Item 3
[ ] Item 4

new features  are separate from the real problem list, which is better.

thanks for the recommendation.


Data Skew

I'm curious about mechanisms to address data skew in sorting/shuffling/merge operations, where some values are far more common than others.  This comes up a lot when talking to Spark people as a common thing to watch out for.  It's also a non-trivial pain point for some dask.dataframe users.
I think a useful benchmark to explore and become sensitive to these workloads is the RenRe workflow some folks here have.
Quantiles help, but maybe not enough?
Maybe what we do today with pre-computing quantiles helps with some of this.  It means that common values are more likely to be alone in their own partition, rather than with lots of other data (this would happen if we hash, for example).  Maybe that's why it has been less of a concern for us than for Spark people historically?
Beyond that though, let's consider the case where there is a single value that is very common, and we're doing some join-like operation that expands it even further.  How can we avoid memory blowing up?
Solutions
Spark uses iterative algorithms, kind of like how we operate in dask.bag today.  They consume chunks of dataframes and emit chunks of dataframes.  We could maybe do something similar in some cases
After blockwise fusion could look at fused expressions and find any that have joins in them.  Probably we could switch these to run the same set of blockwise operations, but in a for loop over smaller bits of data coming in.  This is only beneficial if there are one of two other kinds of nodes in the fused expression after the join / expanding operation:

The beginning of an ApplyConcatApply sequence.  This likely reduces the data, and then we can throw in an extra concat and combine at the end of the first apply stage.
Writing to parquet/csv where we probably write each chunk as a row group or something to some data sink

Timing
This feels important, but not urgent.  I don't think that we should think too much about it until after we've got dask-expr replacing dask.dataframe and good performance on benchmarks that don't include much skew.
Probably the one thing to do early-ish is to see how dask-expr and the new p2p system perform on the RenRe benchmark. cc @fjetter

I remember the RenRe problem to suffer mostly from bloating data. There was an outer join + groupby that generated so many groups that we couldn't handle it without split_out. With split_out shuffle perf was just abysmal. Haven't looked at this in a long time, though.
Regardless of whether this is a good example, data skew is of course still an issue we should think about.