Make std.traits.Select work for compile-time expressions

Patch contains trailing whitespace.
So I guess it's an alias vs enum thing? LGTM.

Fixed. Yes, you can't alias an expression, but you can Alias the result it if it's ctfe-able.
It's a pity Alias isn't public.

And now I know why Alias isn't public. Ugh. It can't tell the difference between a single element AliasSeq and a single argument.

depends on https://github.com/D-Programming-Language/phobos/pull/3985

I think this should be good to go now that https://github.com/D-Programming-Language/phobos/pull/3985 is merged.

LGTM

Auto-merge toggled on


grad illegally

A CNN+LSTM network was implemented with keras. When I run my program, an error occurred. However, this program can run in another computer properly. The version of keras and theano are up-to-the-minute.
File "image_caption.py", line 327, in
model.fit([images, partial_captions], next_words,validation_data=([images_val, partial_captions_val],next_words_val), batch_size=12, nb_epoch=100)
File "/usr/local/lib/python2.7/dist-packages/keras/models.py", line 642, in fit
sample_weight=sample_weight)
File "/usr/local/lib/python2.7/dist-packages/keras/engine/training.py", line 1107, in fit
self._make_train_function()
File "/usr/local/lib/python2.7/dist-packages/keras/engine/training.py", line 720, in _make_train_function
self.total_loss)
File "/usr/local/lib/python2.7/dist-packages/keras/optimizers.py", line 200, in get_updates
grads = self.get_gradients(loss, params)
File "/usr/local/lib/python2.7/dist-packages/keras/optimizers.py", line 62, in get_gradients
grads = K.gradients(loss, params)
File "/usr/local/lib/python2.7/dist-packages/keras/backend/theano_backend.py", line 825, in gradients
return T.grad(loss, variables)
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 553, in grad
grad_dict, wrt, cost_name)
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1317, in _populate_grad_dict
rval = [access_grad_cache(elem) for elem in wrt]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 965, in access_term_cache
output_grads = [access_grad_cache(var) for var in node.outputs]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1272, in access_grad_cache
term = access_term_cache(node)[idx]
File "/usr/local/lib/python2.7/dist-packages/theano/gradient.py", line 1189, in access_term_cache
i, term.type.dtype))
TypeError: Subtensor{:int64:}.grad illegally  returned an integer-valued variable. (Input index 0, dtype bool)

This is a problem of theano-0.9.0-dev4. I replaced it with theano-0.8.2, this problem disappeared.

Can you make a report on Theano with code to reproduce it so that we fix it?
When did you updated the last time Theano to the dev version? There was a
few days with problems of grad related to the new bool dtype in Theano. So
updating Theano again to the head version could fix this if you didn't
installed Theano in the last few days.
On Wed, Nov 23, 2016 at 7:33 AM, Tommeychang<EMAIL_ADDRESS>wrote:

Closed #4484 https://github.com/fchollet/keras/issues/4484.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fchollet/keras/issues/4484#event-869625918, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALC-1QvqKj7jk3sXQNXhmphzkf0-KwHks5rBDKtgaJpZM4K6UDN
.

When I came across this problem, I updated the theano immediately, which did not fix this problem.
After I found the problem is caused by theano, I have reported this problem to Theano and send my code to them. I think they will fix this bug.
I am sorry that I may be unable to reproduce this problem now. As a program is running in that computer and it will last for two days.

Just to help make the follow up, it was reported in Theano on:
https://github.com/Theano/Theano/issues/5274
On Thu, Nov 24, 2016 at 2:57 AM, Tommeychang<EMAIL_ADDRESS>wrote:

When I came across this problem, I updated the theano immediately, which
did not fix this problem.
After I found the problem is caused by theano, I have reported this
problem to Theano and send my code to them. I think they will fix this bug.
I am sorry that I may be unable to reproduce this problem now. As a
program is running in that computer and it will last for two days.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fchollet/keras/issues/4484#issuecomment-262712342,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALC-xPHliR9x9oKTCIDIpjKc1EbFqjLks5rBUN3gaJpZM4K6UDN
.


jsonRepresentation can not cast to AnyObject

In v1.0.8
I can do this directly(obj is a class object confirm to BasicMappable)
  var basic = [String: AnyObject]()
  basic["obj"] = obj.jsonRepresentation()

But in v2, it won't work and I can't even cast to AnyObject
if let dict = try obj.jsonRepresentation() as? AnyObject {
  basic["obj"] = dict
}

I'm using Alamofire to do a POST which take Dictionary<String, AnyObject> as parameter and assemble to string automatically, does there a way to do things like before?

Currently, I'm doing a tricky way by transform Json -> description -> data -> object
let text = try obj.jsonRepresentation().description
let dict = try NSJSONSerialization.JSONObjectWithData(text.dataUsingEncoding(NSUTF8StringEncoding)!, options: .AllowFragments)
basic["obj"] = dict

Same problem here.

@jhihguan @douglasd3
This is an issue related to moving away from Foundations implicit casting.  If you're in a Foundation environment, you'll need to tag onto the end:
try obj.jsonRepresentation().anyValue

It may be worth wrapping it:
extension MappableObject {
    func foundationJsonRepresentation() throws -> AnyObject {
        return try jsonRepresentation().anyValue
    }
}

Let me know if this solves your problem guys and any input into how you'd prefer to interact with the api.

I also wanted to mention, that if you're looking for type [String : AnyObject], you can do:
try obj.jsonRepresentation().foundationDictionary

@LoganWright
There's an issue when accessing anyValue
I created a PullRequest in JsonSerializer

@jhihguan I went ahead and grabbed that right now, thank you for the fix!
If you update your pod, you should be good to go.  Make sure it bumps you to 1.0.2 of the JsonSerializer

Thanks @LoganWright
Here's my opinion about this
I think it would be great to have this info (anyValue, foundationDictionary) show on README?
Cause for me, the json means Dictionary class. It will help developer figure out how they can get the true dictionary object.
Here's my lazy thought
Besides, it good for me if this is built in (also the foundationDictionary), so I don't have to import another library (sorry for lazy...)
extension MappableObject {
    func foundationJsonRepresentation() throws -> AnyObject {
        return try jsonRepresentation().anyValue
    }
}

I'm fine with the usage of jsonRepresentation().anyValue, just throw out my thought
Thanks again :)

@jhihguan
I think that would be a great addition while people are getting used to Json as an enum.  I think I'd go one step further and say it should return [String : AnyObject].
We could also write an implementation of this on collectionType that returns: [AnyObject].
I think that would cover a good amount of use cases.

In 3.0,

foundationJSON
foundationDictionary
foundationArray


Root group with an option and no command raises "Missing command"

Python 3.6
click==6.7
Root group with an option raises a "Missing command" error
https://github.com/pallets/click/blob/0d9731e/tests/test_commands.py#L103
Currently,
    result = runner.invoke(cli, ['-c', '/path/to/config'])

would result in Missing Command being raised. Despite the fact only the root cli object is being accessed. In other words:
$ program -c /config/file
Wouldn't work. Despite the fact the root cli function can have logic and gets the option information anyway.
But $ program would work.
The click library shouldn't force routing to a command just because an option is used. In my situation I want to:

bootstrapping (create config directories, download initial db stuff, anything)
creating an object, but not nescessarily passing down context to commands)

The desired and intuitive behavior, imo, would be to treat $ prog --option optionval the same as $ prog but just pass the option in.

I'm closing this because the assumption I make on the behavior of the root cli function is incorrect.


document bug report : forward function np.exp cannot apply to chainer.Variable

in this page : https://docs.chainer.org/en/stable/tutorial/function.html
class ExpAdd(Function):
    def forward_cpu(self, inputs):
        x, y = inputs
        z = np.exp(x) + np.exp(y)
        return z,

    def backward_cpu(self, inputs, grad_outputs):
        x, y = inputs
        gz, = grad_outputs

        gx = gz * np.exp(x)
        gy = gz * np.exp(y)
        return gx, gy

    def forward_gpu(self, inputs):
        cupy = cuda.cupy
        x, y = inputs
        z = cupy.exp(x) + cupy.exp(y)
        return z,

    def backward_gpu(self, inputs, grad_outputs):
        cupy = cuda.cupy
        x, y = inputs
        gz, = grad_outputs

        gx = gz * cupy.exp(x)
        gy = gz * cupy.exp(y)
        return gx, gy

def expadd(x, y):
    return ExpAdd()(x, y)

np.exp or cupy.exp cannot apply chainer.Variable, this means chainer self define function cannot use the power of numpy or cupy, that we can only use chainer.functions lib??

The inputs and grad outputs of forward and backward methods of Function are all numpy/cupy arrays, so it's valid to apply np or cupy functions.

@beam2d oh, may be I don't fully understand Function yet, the document written:"Function acts like a function on Variable objects that returns Variable objects as outputs, whereas these objects do not appear directly in the graph".   When did it convert chainer.Variable to np or cupy before forward or backward function?


Undefined value using select with react hook form

Hello!
I don't know why my form submission doesn't pass the validation check using react hook form and radix select primitive.
After selecting a value, this one still undefined and the resolvers do it's job telling me the field is required.
The form :

useForm:

Any idea ?

You need to use the Controller component from react-hook-form: https://react-hook-form.com/get-started/#IntegratingwithUIlibraries

You might need to use the Controller component from react-hook-form: https://react-hook-form.com/get-started/#IntegratingwithUIlibraries.
When spreading the register('field') you are passing onChange but the Select.Root is expecting onValueChange.
Here is a working example https://codesandbox.io/s/shadcn-ui-select-react-hook-form-mgmdmv

It works, thanks!

@emicba thanks for sharing, ran into the same issue 🙏


added jwt2header plugin for plugins hub

added community developed JWT 2 Header / Route by JWT plugin per guidelines at https://github.com/Kong/docs.konghq.com/blob/master/CONTRIBUTING.md#kong-hub-contributions

@lena-larionova All changes confirmed. ty!

@lena-larionova , this was displaying fine before, but after your changes, it now is not visible in preview mode? Any idea why?

@lena-larionova - figured it out. in the default values for parameters, you had forgotten to put double quotes around the single quotes. made that change and all is working now. Should be ready to post.


Properly read etags from GET responses

Description
GET responses weren't setting the etag correctly
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to
implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Tests pass
[ ] Created/updated tests
[ ] Extended the documentation

Codecov Report

Merging #92 (1a12d9c) into main (8c6dda2) will decrease coverage by 0.15%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##               main      #92      +/-   ##
============================================
- Coverage     73.76%   73.61%   -0.16%
  Complexity      396      396
============================================
  Files            49       49
  Lines          1456     1459       +3
============================================
  Hits           1074     1074
- Misses          382      385       +3

Impacted Files
Coverage Δ
Complexity Δ

src/lib/DaprClient.php
0.00% <0.00%> (ø)
18.00 <0.00> (ø)

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 8c6dda2...1a12d9c. Read the comment docs.


loading doesn't stop if the node is not responding

https://github.com/threefoldtech/tfgrid-sdk-ts/assets/41957921/b572de6a-8edf-4d41-b539-3af5f4d9ea9e

The issue happened because of the the grid prox, but of course, it needs to be handled from our side

PS: Waiting on new style will be provided by @ehab-hassan

https://www.figma.com/proto/b50GilnYwLrhwOUIhfzHNA/dashboard-Nav?type=design&node-id=1267-2525&t=MoDFEiajud7rXrwN-0&scaling=contain&page-id=0%3A1&starting-point-node-id=124%3A196

Update the build method in the proxy client to set timeout 5000 on the request and return an error in case the node is not responding,
Update the node details with a re-request button to let the user re-request the node in case of not responding.
Updated the dialog header size
Updated the style of error loading the node

Verified,
Devnet 8c32384.
When the node is not responding or an error occurs, the try again message is shown.

TC2252 - Offline/Standby Nodes Information

Verified:

Devnet
000eea2


Use KV to store notify patterns

Instead of using an environment variable to store a single notify pattern, we should use KV to store a list of patterns.
README and bootstrap script updated accordingly.

What do you prefer?

Merge commit
Squash and merge
Rebase without a merge commit

I vote for squash and merge.


feat(topic_entity_tag): new icons for sorting

Clicking three times goes back to non-sorted results

Yes, I couldn't find the double icon arrow and I set the down arrow (not colored) as default, but I can add the default sort icon if we find it

Gotcha, cool

I found the icons in font awesome, but not in react icons (which is supposed to be a meta project containing also fa icons). I'll update them


Delay allocating stacktrace buffer until necessary

Right now CallUserFunction will always allocate a byte slice to store stack traces. Delaying the allocation of the byte slice until it is absolutely necessary drastically increases the performance of this method (~3x on my machine).
Potential downside of this is that we might be unable to allocate memory when the panic occurs. However, I think go will still give us a pretty solid error message in that case.

Love it. Thanks @DianeLooney.


JSON field name must contain dot(period) character

Fixes #1571

@baijum snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1572-1

[test]

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@aac49ff). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #1572   +/-   ##
=========================================
  Coverage          ?   56.58%
=========================================
  Files             ?      126
  Lines             ?    15330
  Branches          ?        0
=========================================
  Hits              ?     8675
  Misses            ?     6009
  Partials          ?      646

Impacted Files
Coverage Δ

workitem/expression_compiler.go
80.91% <100%> (ø)

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 aac49ff...8562f4f. Read the comment docs.

Hi @baijum ,
I did not understand the context of the discussion well even after reading https://github.com/fabric8-services/fabric8-wit/issues/1571
Do you mind adding a small example to show why this patch is a good idea?

@sbose When building sub-queries using In operator, we need to constructs queries which involve where clauses with fields/columns in different tables.
Here is an example future query: criteria.In("id", criteria.Select("areas", criteria.Equals(criteria.Field("name"), criteria.Literal("planner")), "id"))
In this case without this PR, I need to add name as a hard-coded value in the fieldMap here:
https://github.com/fabric8-services/fabric8-wit/blob/master/workitem/expression_compiler.go#L51
But the string name is too generic, and this will prevent us from using name as a JSON field.

@baijum snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1572-2

[test]


Better indicate incoming interests

Right now, if you don’t have notifications enabled for interests, then it’s likely to miss these messages, because you only see the messages link on your projects page (the envelope button).
New messages could be indicated somewhere in the navigation bar. (This would probably also include adding something like marking interests as read to only indicate the latest unread ones?)

How about a notification area? The user will receive notification about the new messages, new projects published, and news updates from Adoptoposs

:+1: I like the idea. Maybe we can start with a "Messages" link in the navigation bar and a new messages page/notification area, that shows all the messages for projects a user received.
Newly published projects (only for your subscribed languages) are currently shown on the dashboard page (root url for logged in users). But I like the idea to indicate when they showed up. So we can add notifications for new projects in a second step.
And I think it’s a good idea to also have Adoptoposs related notifications in the upcoming notification area. It will make it easier to announce features, privacy policy changes, etc.

Let me build a proof of concept to see how we can improve it.
On Wed, 3 Jun 2020 at 12:36 AM, Paul Götze<EMAIL_ADDRESS>wrote:

👍 I like the idea. Maybe we can start with a "Messages" link in the
navigation bar and a new messages page/notification area, that shows all
the messages for projects a user received.
Newly published projects (only for your subscribed languages) are
currently shown on the dashboard page (root url for logged in users). But I
like the idea to indicate when they showed up. So we can add notifications
for new projects in a second step.
And I think it’s a good idea to also have Adoptoposs related notifications
in the upcoming notification area. It will make it easier to announce
features, privacy policy changes, etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/adoptoposs/adoptoposs/issues/68#issuecomment-637669611,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIPL2KSWSAMNNHGM7JDAR3RUUTAZANCNFSM4NDP2ICQ
.

--
Thank you.
Sky


tenant: Raise a UserError on status_code >= 400 returned from server

To have keylime_tenant return with exit code != 0 upon errors, raise a UserError when the server returns a status_code != 200.

Expecting several test case failures now ...

I do not understand why /functional/db-mysql-sanity-on-localhost is being executed on Fedora, this one should be skipped there. Maybe there is some regression in the Testing Farm or Packit infrastructure.

I do not understand why /functional/db-mysql-sanity-on-localhost is being executed on Fedora, this one should be skipped there. Maybe there is some regression in the Testing Farm or Packit infrastructure.

Yes, this was an issue on Testing Farm side but it is fixed now.

/packit retest-failed

/packit retest-failed

I am working on test update in https://github.com/RedHat-SP-Security/keylime-tests/pull/366 but (other) tests are failing, most likely this PR needs rebase.

I am working on test update in RedHat-SP-Security/keylime-tests#366 but (other) tests are failing, most likely this PR needs rebase.

We have test updates ready. I can merge them when requested.

@kkaarreell yeah lets merge it :+1:

@kkaarreell yeah lets merge it +1

done

/packit retest-failed

F38 Is expected to fail. F37 errored out due to a known but not troubleshooted issue of AWS systems not rebooting properly. Rerun would most likely pass.

/packit retest-failed


fix generate_combinations issue with Linux Qt 6.7

Fix issues discovered in #751. See https://github.com/miurahr/aqtinstall/pull/751#issuecomment-1935347831
Qt 6.7.0 changes the default arch for Linux from gcc_64 to linux_gcc_64. This allows the generate_combinations.py script to account for that.
Also, Qt 6.7.0 is missing a few architectures that were present in earlier versions of Qt6. This makes sure that the script can pick those up.

Shouldn't CI for this PR actually run the generate_combinations.py script, or did we not set it up to do that?


[backport] Fix dead link to issue

Backport of #4736

(Jenkins not needed)

Confirmed it appeared correctly in RTD


New volume rendering and iso contour control

updated volume rendering code
added iso surface rendering control
removed limited zoom in

go ahead , you can commit on visus_javascript directly


argocd:create-resources: unable to verify the first certificate

Issue
Is there a way to by pass such a TLS Certificate issue reason: unable to verify the first certificate when we create a new argocd resource using the action
    - id: create-argocd-resources
      name: Create ArgoCD Resources
      action: argocd:create-resources
      input:
        appName: ${{ parameters.component_id }}-bootstrap
        argoInstance: argocdQShift # Match appconfig => argocd/appLocatorMethods/instances/name
        namespace: ${{ parameters.namespace }}
        repoUrl: ${{ steps.publish.output.remoteUrl }}
        labelValue: ${{ parameters.name }}
        path: 'argocd/'

Error reported
2024-01-25T12:03:02.000Z Beginning step Create ArgoCD Resources22024-01-25T12:03:02.000Z FetchError: request to https://openshift-gitops-server-openshift-gitops.apps.qshift.snowdrop.dev//api/v1/session, Opens in a new window failed, reason:
unable to verify the first certificate3    at
ClientRequest.<anonymous> (/opt/app-root/src/dynamic-plugins-root/roadiehq-scaffolder-backend-argocd-dynamic/node_modules/node-fetch/lib/index.js:1501:11)4    at
ClientRequest.emit (node:events:517:28)5    at
TLSSocket.socketErrorListener (node:_http_client:501:9)6    at
TLSSocket.emit (node:events:517:28)7    at
emitErrorNT (node:internal/streams/destroy:151:8)8    at
emitErrorCloseNT (node:internal/streams/destroy:116:3)9    at
process.processTicksAndRejections (node:internal/process/task_queues:82:21)

Please dont unstale it as it still need roadie feedback


Fixed -v arg for Docker quick start

Codecov Report

Merging #143 into master will decrease coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #143      +/-   ##
==========================================
- Coverage   75.04%   74.86%   -0.18%
==========================================
  Files           5        5
  Lines         565      565
==========================================
- Hits          424      423       -1
- Misses        120      123       +3
+ Partials       21       19       -2

Flag
Coverage Δ

#unittests
74.86% <ø> (-0.18%)
:arrow_down:

Impacted Files
Coverage Δ

selenoid.go
73.82% <0%> (-0.34%)
:arrow_down:

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 37c2cee...368bfbb. Read the comment docs.


Profiling shader compiles

Where could I plug in into cepl to see where all the compile time goes. For example to see how long it took for varjo to generate the glsl and how long for cepl to compile that and how long for the driver to do its thing. Currently this is the best I got and what strikes a little odd to me is the growth rate of the compile times.
node count     Compile time     evaluation time for first pulse
100                 3                       6
200                 20                      30
300                 65                      75
400                 151                     157
500                 290                     282
600                 490                     475
700                 762                     735
800                 1113                    1053

I would like to know where to hack in some timers to start finding out why are the compile times almost doubling for each 100 new nodes.
Testing with model size 100

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  3.041 seconds of real time
  3.967538 seconds of total run time (3.966541 user, 0.000997 system)
  130.48% CPU
  149 forms interpreted
  163 lambdas converted
  10,319,106,454 processor cycles
  495,139,840 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  5.780 seconds of real time
  6.662023 seconds of total run time (6.652977 user, 0.009046 system)
  115.26% CPU
  19,615,170,554 processor cycles
  672,522,800 bytes consed

Testing with model size 200

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  19.982 seconds of real time
  20.870541 seconds of total run time (20.853585 user, 0.016956 system)
  [ Run times consist of 0.083 seconds GC time, and 20.788 seconds non-GC time. ]
  104.45% CPU
  149 forms interpreted
  163 lambdas converted
  67,811,171,786 processor cycles
  3,106,125,504 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  27.586 seconds of real time
  29.539649 seconds of total run time (29.507746 user, 0.031903 system)
  [ Run times consist of 0.068 seconds GC time, and 29.472 seconds non-GC time. ]
  107.08% CPU
  93,614,211,678 processor cycles
  3,085,017,856 bytes consed

Testing with model size 300

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  65.239 seconds of real time
  65.256901 seconds of total run time (64.582948 user, 0.673953 system)
  [ Run times consist of 0.426 seconds GC time, and 64.831 seconds non-GC time. ]
  100.03% CPU
  149 forms interpreted
  163 lambdas converted
  221,391,446,318 processor cycles
  9,769,012,528 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  73.369 seconds of real time
  75.373209 seconds of total run time (75.302119 user, 0.071090 system)
  [ Run times consist of 0.109 seconds GC time, and 75.265 seconds non-GC time. ]
  102.73% CPU
  248,986,798,386 processor cycles
  9,244,122,480 bytes consed

Testing with model size 400

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  151.094 seconds of real time
  151.137313 seconds of total run time (151.095348 user, 0.041965 system)
  [ Run times consist of 0.175 seconds GC time, and 150.963 seconds non-GC time. ]
  100.03% CPU
  149 forms interpreted
  163 lambdas converted
  512,752,183,516 processor cycles
  22,408,958,112 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  154.922 seconds of real time
  157.037775 seconds of total run time (156.951759 user, 0.086016 system)
  [ Run times consist of 0.139 seconds GC time, and 156.899 seconds non-GC time. ]
  101.37% CPU
  525,742,357,612 processor cycles
  20,930,222,064 bytes consed

Testing with model size 500

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  289.905 seconds of real time
  289.987524 seconds of total run time (289.915504 user, 0.072020 system)
  [ Run times consist of 0.271 seconds GC time, and 289.717 seconds non-GC time. ]
  100.03% CPU
  149 forms interpreted
  163 lambdas converted
  983,818,189,706 processor cycles
  42,696,772,240 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  282.366 seconds of real time
  282.845360 seconds of total run time (282.080342 user, 0.765018 system)
  [ Run times consist of 0.664 seconds GC time, and 282.182 seconds non-GC time. ]
  100.17% CPU
  958,234,426,184 processor cycles
  39,671,882,128 bytes consed

Testing with model size 600

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  489.712 seconds of real time
  491.392494 seconds of total run time (490.554430 user, 0.838064 system)
  [ Run times consist of 0.620 seconds GC time, and 490.773 seconds non-GC time. ]
  100.34% CPU
  149 forms interpreted
  163 lambdas converted
  1,661,882,144,808 processor cycles
  73,333,848,736 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  473.982 seconds of real time
  476.254795 seconds of total run time (475.292807 user, 0.961988 system)
  [ Run times consist of 0.646 seconds GC time, and 475.609 seconds non-GC time. ]
  100.48% CPU
  1,608,502,247,318 processor cycles
  68,024,845,712 bytes consed

Testing with model size 700

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  761.911 seconds of real time
  762.146622 seconds of total run time (760.288702 user, 1.857920 system)
  [ Run times consist of 1.435 seconds GC time, and 760.712 seconds non-GC time. ]
  100.03% CPU
  149 forms interpreted
  163 lambdas converted
  2,585,614,719,840 processor cycles
  114,807,390,688 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  734.478 seconds of real time
  736.841229 seconds of total run time (735.691283 user, 1.149946 system)
  [ Run times consist of 0.694 seconds GC time, and 736.148 seconds non-GC time. ]
  100.32% CPU
  2,492,517,967,558 processor cycles
  106,334,035,200 bytes consed

Testing with model size 800

"Creating new model."
; recompile cpu side of (MODEL-PIPELINE ...)
Evaluation took:
  1113.312 seconds of real time
  1113.678566 seconds of total run time (1110.259724 user, 3.418842 system)
  [ Run times consist of 1.508 seconds GC time, and 1112.171 seconds non-GC time. ]
  100.03% CPU
  149 forms interpreted
  163 lambdas converted
  3,778,127,183,534 processor cycles
  171,264,476,448 bytes consed

"Evaluating model."
; uploading (MODEL-PIPELINE ...)

NIL
Evaluation took:
  1051.559 seconds of real time
  1054.126414 seconds of total run time (1051.151391 user, 2.975023 system)
  [ Run times consist of 1.699 seconds GC time, and 1052.428 seconds non-GC time. ]
  100.24% CPU
  3,568,560,603,608 processor cycles
  158,598,094,352 bytes consed

Im very willing to believe that varjo is too slow, I've never done any work on making that quick (though funnily I was just thinking about this before I saw this ticket). Also CEPL is trying to propagate changes from gpu-functions (which means recompiling all gpu-funcs & pipelines that use it) That is going to have some nasty speed repercussions as more functions are in the system.
What are nodes & pulses in this case? I'd be quite interested in your test setup.
cepl.pipelines Is where all the logic for compilation is. rolling-translate is the function from varjo that cepl  calls to compile things.
Thanks for looking into this. Im a tad nervous as I know how messy a lot of this stuff is but also excited with the idea that we can make it faster

ok so I made a quick test. https://github.com/cbaggers/varjo/blob/feature/perf/protocode/profile.lisp
I run profile-all-varjo which instruments all the functions. I then call gooo passing in a list of stages to be compiled together. it runs this 30 times so we get enough data. I then dumped out the results here https://github.com/cbaggers/varjo/blob/feature/perf/protocode/varjo-perf-issues.ods
The second page has the graphs of some of the worst offenders. But the results are not too surprising. I can see things that will be easy for me to start looking at and it might be that those things alone will be enough to get some better build times.

This was my hacky test
(gooo
   (mapcar #'varjo.internals:starting-stage
			   (v-compile
				'((tess-level-inner :float) (tess-level-outer :float)
				  (projection :mat4) (model->clip :mat4) (normal-mat :mat3)
				  (light-position :vec3) (diffuse-material :vec3) (ambient-material :vec3))
				:410
				:draw-mode '(:patch 3)

				:vertex
				'(((position :vec4))
				  (values position
				   (s~ position :xyz)))

				:tessellation-control
				'(((position (:vec3 3)))
				  (declare (output-patch :vertices 3))
				  (let ((tess-level-inner 5f0)
						(tess-level-outer 5f0))
					(when (= gl-invocation-id 0)
					  (setf (aref gl-tess-level-inner 0) tess-level-inner
							(aref gl-tess-level-outer 0) tess-level-outer
							(aref gl-tess-level-outer 1) tess-level-outer
							(aref gl-tess-level-outer 2) tess-level-outer)))
				  (aref position gl-invocation-id))

				:tessellation-evaluation
				'(((position (:vec3 3)))
				  (declare (tessellate-to
							:primitive :triangles
							:spacing :equal
							:order :ccw))
				  (let* ((p0 (* (x gl-tess-coord) (aref position 0)))
						 (p1 (* (y gl-tess-coord) (aref position 1)))
						 (p2 (* (z gl-tess-coord) (aref position 2)))
						 (pos (normalize (+ p0 p1 p2))))
					(values
					 (* model->clip (v! pos 1))
					 pos
					 gl-tess-coord)))

				:geometry
				'(((position (:vec3 3)) (patch-distance (:vec3 3)))
				  (declare (output-primitive :kind :triangle-strip
							:max-vertices 3))
				  (let* ((a (- (aref position 2) (aref position 0)))
						 (b (- (aref position 2) (aref position 0)))
						 (facet-normal (* normal-mat (normalize (cross a b)))))
					(emit ()
						  (gl-position (aref gl-in 0))
						  (aref patch-distance 0)
						  facet-normal
						  (v! 1 0 0))
					(emit ()
						  (gl-position (aref gl-in 1))
						  (aref patch-distance 1)
						  facet-normal
						  (v! 0 1 0))
					(emit ()
						  (gl-position (aref gl-in 2))
						  (aref patch-distance 2)
						  facet-normal
						  (v! 0 0 1))
					(end-primitive)
					(values)))

				:fragment
				'(((patch-distance :vec3) (facet-normal :vec3) (tri-distance :vec3))
				  (labels ((amplify ((d :float) (scale :float) (offset :float))
							 (let* ((d (+ (* scale d) offset))
									(d (clamp d 0 1)))
							   (- 1 (expt (* d d -2) 2)))))
					(let* ((light-position (v! 0 1 0))
						   (diffuse-material (v! 1 0 0))
						   (ambient-material (v! 0.2 0.2 0.2))
						   ;;
						   (n (normalize facet-normal))
						   (l light-position)
						   (df (abs (dot n l)))
						   (color (+ ambient-material (* df diffuse-material)))
						   (d1 (min (min (x tri-distance) (y tri-distance))
									(z tri-distance)))
						   (d2 (min (min (x patch-distance) (y patch-distance))
									(z patch-distance)))
						   (color (* (+ ambient-material (* df diffuse-material))
									 (amplify d1 40 -0.5)
									 (amplify d2 50 -0.5))))
					  (v! color 1))))))

Haven't taken a look at the results you got yet, but will when I get the time. In the mean time, let me answer some of your questions.
The nodes are the base units of the GP system, which means in this case procedures from which the models are constructed from. A simple example, however, useless one of a node would be in glsl as
void LIB_EXPR_0(MODEL DATA)
{
    if ((DATA.NODES[int(gl_WorkGroupID.x)].INPUTS[0] == 58))
    {
        for (int I = 0;(I < 10);(++ I))
        {
            int OUTPUT_SLOT = DATA.NODES[int(gl_WorkGroupID.x)].OUTPUTS[I];
            int OUTPUT_NODE = int(trunc(float((OUTPUT_SLOT / 10))));
            DATA.NODES[OUTPUT_NODE].INPUTS[int(mod(float(OUTPUT_SLOT),float(10)))] = 42;
        }
    }
    return;
}

This is something the system did write on its own and fed to varjo.
In the models I am constructing, I have currently three ways to represent these nodes; As individual functions as depicted above, as inline code withing a call-tree or as a labels section preceding the call tree. I have an example call-tree depicted below. It is very inefficient and I should turn that to a binary tree instead, but it works.
void MODEL_SHADER()
{
    int NODE_ID = int(gl_WorkGroupID.x);
    if ((NODE_ID == 0))
    {
        LIB_EXPR_0(DATA);
    }
    else
    {
        if ((NODE_ID == 1))
        {
            LIB_EXPR_1(DATA);
        }
        else
        {
            if ((NODE_ID == 2))
            {
                LIB_EXPR_2(DATA);
            }
            else
            {
                if ((NODE_ID == 3))
                {
                    LIB_EXPR_3(DATA);
                }
                else
                {
                    if ((NODE_ID == 4))
                    {
                        LIB_EXPR_4(DATA);
                    }
                    else
                    {
                        if ((NODE_ID == 5))
                        {
                            LIB_EXPR_5(DATA);
                        }
                        else
                        {
                            if ((NODE_ID == 6))
                            {
                                LIB_EXPR_6(DATA);
                            }
                            else
                            {
                                if ((NODE_ID == 7))
                                {
                                    LIB_EXPR_7(DATA);
                                }
                                else
                                {
                                    if ((NODE_ID == 8))
                                    {
                                        LIB_EXPR_8(DATA);
                                    }
                                    else
                                    {
                                        if ((NODE_ID == 9))
                                        {
                                            LIB_EXPR_9(DATA);
                                        }
                                        else
                                        {
                                            false;
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
    return;
}

Pulses in this case are the events of calling map-g on the model shader with some input data. In the test depicted in the first post, the data was a simple blank buffer. In this case all nodes are gone through and nothing happens. Therefore, the majority of the time taken by the first pulse, is the time it takes to upload the model to the gpu.
Having the three ways to compile the model, I decided to do a little test to find what way would be the most efficient. I set for my computer to compile 12 models; four with all three ways. The models compiled were of sizes 500, 1000, 1500 and 2000. Originally I thought that the method of separating the node functions outside of the main shader would be the fastest as there would be four threads compiling the nodes. And I thought that the inline definition would be the second fastest as less code would be written than with the labels section. However, here are the results.
nodes   inline   labels   modular
 500       .6      .15      .4
1000      5       1.2      3.6
1500     13.8     3.8     10.4
2000      DNF     8.1      DNF

The compile times are in hours. As you can see, I was incorrect in my assumptions. The questions this unexpected order raises come to how cepl and varjo handle the shaders. Firstly you stated that cepl may be recompiling every shader every time they are needed, or so I understood, and this explains the result gotten for the modular approach. However, this does not explain why having a separate labels section lisp side as opposed to defining every node inline would be that much faster. The other hypothesis I get leads me to ask, how does varjo handle whitespace. Is the shader compiled into a compact format and spaced out and indented when called for printing, or is it compiled into this human friendly format? This question comes from the fact that in the inline function definition model, the node functions quite literally have thousands of levels of indentation, which looks quite trippy in emacs when looking at it.
When running the models, I have ten threads to use for compiling, one to manage the model on the gpu, and the last one to pre-process input data. If I want to have each model be tested for an hour, I need to have the compilation of the next one take at maximum ten hours. Or in other words have one model ready every hour. With model size of 2000 and using the labels section, this should not pose a problem. However, my initial calculations show that the models would end up in the size class of 10000+ nodes and there I get the problem.
I'll use those profiling functions you showed sometime soon and see what kind of results I get. And I would like to know if I can force cepl to not compile any shaders unless separately asked to and see if something changes.

Thanks for all the info. I think I understand more of this now
A node is a function. The function can be inlined, a local function (using labels) or 'modular' which (I think) is a separate CEPL gpu-function (defined with defun-g). So when you say 2000 nodes (in the timing information) it's 2000 functions.
Also I wanted to ask: When you labels section are you taking about labels or something else? I'm not used to the terminology of section in lisp being used in this context.

However, this does not explain why having a separate labels section lisp side as opposed to defining every node inline would be that much

To answer the inlining question I'd need to know how you are doing the inlining. CEPL & Varjo don't have inline declarations so I guess you are using gpu-macros (or generating the inline code yourself?). Any info here will help me find out why that is slower.

Firstly you stated that cepl may be recompiling every shader every time they are needed,

Not quite, sorry if I was confusing. If a gpu-function is compiled it will trigger the recompilation of functions/pipelines that use it. This is so we get live update when modifying our GPU code as it is running. (there is also going to be a final compilation of the whole pipeline which may be deferred to when the pipeline is first called, this is loosely defined so I have the option to do it at compile time if I want)
In summary:
When a defun-g is compiled it:

calls varjo to test compile the code. This makes sure there is at least 1 shader stage this code would be valid in.
recompiles any gpu-functions that use this function
recompiles any pipelines that use this function as a stage

Also. When a defpipeline is recompiled:

regenerates it's lisp code, but doesn call varjo

When a pipeline is first called

Varjo is called to compile the stages and the results are cached.

leads me to ask, how does Varjo handle whitespace

Regarding style of generated glsl, like you have seen we emit human readable glsl. There is very little advantage to us minifying it and also thousands of levels of indentations sound like really slow GPU code to be honest. GPUs, in general, don't like lots of branching so those huge levels of nesting sounds concerning (but this is runtime performance and shouldnt make a huge difference in compilation time). As you are branching based on an int maybe a switch statement would be better:
TESTS> (glsl-code
		(compile-frag ((a :int :flat)) :450 nil
		  (let (((b :vec4) ))
			(switch a
			  (0 (setf b (vec4 1)))
			  (1 (setf b (vec4 2)))
			  (2 (setf b (vec4 3)))
			  (3 (setf b (vec4 4)))
			  (4 (setf b (vec4 5)))
			  (5 (setf b (vec4 6)))
			  (6 (setf b (vec4 7)))
			  (7 (setf b (vec4 8)))
			  (8 (setf b (vec4 9)))
			  (9 (setf b (vec4 10))))
			b)))
"// fragment-stage
#version 450

in _IN_BLOCK_
{
     flat in int A;
} v_in;

layout(location = 0)  out vec4 _FRAGMENT_STAGE_OUT_0;

void main()
{
    vec4 B;

    switch (v_in.A) {
        case 0:
        B = vec4(float(1));
        break;

        case 1:
        B = vec4(float(2));
        break;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             MORE CODE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        case 9:
        B = vec4(float(10));
        break;
    }
    vec4 g_GEXPR0_15834 = B;
    _FRAGMENT_STAGE_OUT_0 = g_GEXPR0_15834;
    return;
}"

switch returns void in Vari as it's a statement in glsl, that is why we need to assign the result to a local variable.

as there would be four threads compiling the nodes
I'm very confused by this. CEPL does not create any threads, and does not multithread compilation.

Good that we can get to more even ground on this and I'm sorry for my poor terminology, I'm not majoring in computer science, but in finance.
So, indeed a node is a function that can be defined in three ways in the code. The 'modular' being a separate gpu function defined with defun-g, inline being expanded using defmacro-g for all of the functionality that the nodes are allowed to have and with labels, having me refer to different parts of the main function as sections with no further meaning. The term 'section' simply stems from the number of research papers I have had to read.
About using the switch statement, I should probably do that, but haven't yet gotten that far in my development of the system to have time to worry about the runtime performance. The whole system doesn't run at all yet. I was just using a really large cond tree as it allowed me to start working on the next part, which still is getting the data to the model and get something to go through all the way to the end. After a day I can then leave the computer to do some test overnight about applying what I find into the large structure I intend to run this system with.
Last night I tried to improve on the linear cond tree with this binary tree
(defmacro ncond (id-var &rest clauses)
  (if (rest clauses)
    (let* ((half-point (truncate (/ (length clauses)
                                    2.0)
                                 1))
           (last-half (subseq clauses half-point)))
      `(if (< ,(caar last-half) ,id-var)
           (ncond ,id-var ,@(subseq clauses 0 half-point))
         (ncond ,id-var ,@last-half)))
    (cadar clauses)))

I ran the test with the currently best found method of using labels, but I should probably try with the switches too. Any way here is what I got.
nodes       compile-time
 500          15   s
1000           1.5 m
2000          12   m
3000          41   m
4000           1.7 h
5000           2.9 h
6000           4.8 h

As I did expect, the compile times are lower, but I did not expect for them to be this low. The only change being the switch to the ncond as opposed to regular cond. I'll have to see what happens with the switches. I did have some larger ones set up as well, but I ran into some limitations in sbcl. I'll need to do a custom ebuild for that, which shouldn't be too hard on gentoo. And yes I have to agree with you on that the whitespace shouldn't affect much with any type of normal use.
To get to the last question you posted about cepl not being multi-threaded, I know that and just made the treads on my side using (bt:make-thread (lambda () (define-model-here))) As those models were compiled for pure testing of compiling I wasn't that concerned about potential thread safety issues that could happen within cepl. If some problems do come up, we can always fix them.
The specific issue about four threads being used to compile the nodes comes from some machinery I set up with the modular models first compiling all of their nodes before compiling themselves. As I had setup the compiles of the modular models, four of them, to happen simultaneously and use partially the same nodes, resulted in all four threads compiling the functions needed by the first of the models. Then as the smallest model starts to compile itself, the rest three treads continue to compile their needed nodes. And the process continues as long as there are more nodes needed.
To get forward I must thank you for the description on what happens from defun-g onwards. The fact of varjo being called to test compile when the functions are defined with defun-g and then again when they are first needed with (map-g 'pipeline) does explain why the time for the initial pulse from the first post is so similar to the compile time as all that is done there is call map-g on the pipeline with empty data. If I understand correctly, this act of testing results in all of the functions being compiled twice, first to test and second to use. If that is indeed the case, would it be possible to tell cepl and varjo to not do a test compile? As with the system I'm writing, all of the shaders are written by a computer and invalid ones can just be discarded. It won't matter if the invalidness is captured during test compile or real. In a repl environment and development that testing can be quite useful, but when there are numerous large shaders, from which some are expected to fail, and throughput being the major issue, the double compiling doesn't sound beneficial.
Here is what I need to do for every model.

Generate the genome for the model.
Extract each gene from the genome and turn those into descriptions of nodes.
Pile the first half of each of those nodes together into a shader stage using a defun-g.
Link that shader stage to a pipeline using defpipeline-g. this needs to be done once only as the stage can be redefined.
Pile the second half of each  those nodes into the initial connections of the model using make-gpu-array
Call the pipeline on some input data using map-g.
Read the output using pull-g.

Notes to self:
Looking at this two functions stand out:

5.2    VARJO.INTERNALS::TRY-TYPE-SPEC->TYPE
33.1   VARJO.INTERNALS::BASIC-ARG-MATCHP

sprof says that 33% of the time we are in basic-arg-matchp. The important point with these two functions is that most of the functions that sprof saw in the call stack were functions compiling some chunk of code. These two however, do not, and so they are close to the culprits of part of the issue. If we could make these faster it is likely we could make a significant impact on compile time as a whole.
Also both of these make sense as culprits. I'm going to have a think about how we could encode the type info to allow basic-arg-matchp to be faster.

More Notes
Well, I was reading the profile incorrectly. The important bit was:
Evaluation took:
  12.343 seconds of real time
~~~~ but at the bottom ~~~~

     0.785 |      0.015 | 109,752,032 | 4,915,380 |            | Total

estimated total profiling overhead: 10.53 seconds

0.785 for compiling a 5 stage pipeline 30 times isnt amazing..but it's a lot better that what we are seeing in the issue, so I think I need to look at the CEPL side instead.
For another test I turned off profiling and compiled the pipeline (5 stages) 3000 times. It took 40 seconds.
Again these are only indicators, not case closed, but it strongly suggests I need to look at CEPL for the answers

Ok so our string indenting code is dirt slow. I'm going to rewrite all of this

@tsili I havent pushed the fix yet, but for highly nested code the new version of the glsl generation will be at least 10 times faster. I'll let you know when it is in.

Yay! Done a bunch of fixes on the branch. I will merge tomorrow (I just need to run the test suite on a couple of different machines)
Here is an example
(defun yup ()
  ;;             generate a cond with 200 arms
  (let* ((code `(let ((a 1))
                  (flet ((boop ((x :int))
                           (float x)))
                    (cond
                      ,@(loop :for i :below 200 :collect
                           `((= a ,i) (boop ,i))))
                    (v! 1 2 3 4))))
         (stage (make-stage :fragment nil nil '(:450) (list code))))
    (time (translate stage))))

On master

Evaluation took:
5.630 seconds of real time
5.632000 seconds of total run time (5.308000 user, 0.324000 system)

On feature/perf

Evaluation took:
0.167 seconds of real time
0.164000 seconds of total run time (0.164000 user, 0.000000 system)

Great to hear you got this much extra performance. I will do some tests on that too. Before then I could probably give you the results I got with the switch alternative with the profiling on.
results
On the first sheet are results from running several compiles in parallel for 10 minutes using my little hackish method. And on the other sheet are the results from running many compiles one after the other.

No problem with not majoring in CS, neither did I :) It's very cool to hear that CEPL being used for non graphical stuff too.
I do agree that it makes sense to test first before worrying about performance, however I'm wondering if the glsl will compile at all in the end or if the driver will give up. It will be interesting to hear.
When you mentioned (bt:make-thread (lambda () (define-model-here))) I'm wondering what is in (define-model-here). Just a little warning, defun-g & defpipeline-g have to be 'top level forms' so should not be inside a lambda. If you are using lambda-g & pipeline-g then awesome, you are the first person other than me to be using them. However they would have to be used on the thread they are compiled on and so those threads are going to need their own contexts (cepl.examples has an example of this, sadly that part of CEPL is not documented yet)
Currently there is no way to avoid the test compile when making gpu-functions, I do agree this is a problem though so I have opened a ticket for this.
Thanks for the data, I will have a look and see what could be causing such high times for %get-free-glsl-name, likely-recursion-p & replace-substrings-in-name.

I've merged some fixes into master so hopefully you will see the speedup when you next pull.

@tsili Tonight I will be adding CL's case to varjo. This will compile to a glsl switch when it can. It also compiles faster than the nested if and cond do (even after the fixes) so this should help with your project.

Thank you so much. I had been looking for the case before I ended up with the huge cond tree.
I'll get some tests in once I have some extra compute time to use. I'm currently running tests on the data pipeline I have made. And to answer your question about the (define-model-here), it definitely uses simple defun-g at this time within another function and not on the top-level. I'll need to look into that as I get into runtime testing.
Thank you for the pointers about using lamda-g, I should get by with the examples. I haven't gotten as far with lisp to know why some things absolutely need to be on the top-level, but I know I cannot get my model and node definitions there. Therefore, the lambda-g and pipeline-g will come in useful.

OK, get some more tests in with the new versions of cepl and varjo. I have to say these results are once again something unexpected.
nodes       time      average time per node
  100       0.312 s     0.003
 1000     100     s     0.100
 2000       9.7   m     0.291
 3000      34.7   m     0.694
 4000       1.35  h     1.215
 5000       2.48  h     1.786
 6000       4.35  h     2.610
 7000       6.31  h     3.245
 8000       8.89  h     4.001
 9000      12.4   h     4.960
10000      17.4   h     6.264

As you can see, the time per node is still increasing as the models get bigger. Furthermore, the time spent compiling didn't change much. However, there were some improvements in the RAM consumption dropping from occasionally hitting swap on a 16 GB system to using 7-8 GB. I'm not sure of what could cause such a memory consumption drop and not affect the compile time. I'll run some more tests with the profiling on.
Additionally, I did some improvements on how the nodes are represented using GP-feature extraction to compress the nodes' code. Here are the results after adding this system into the mix.
nodes     time      average time per node
 1000     39.50 s     0.04
 2000      4.35 m     0.13
 3000     12.02 m     0.24
 4000     29.00 m     0.44
 5000     55.78 m     0.67
 6000      1.56 h     0.93
 7000      2.44 h     1.26
 8000      3.56 h     1.60
 9000      4.85 h     1.94
10000      6.46 h     2.33

With this I can get that magical 10 000 nodes' compile time under 10 hours and, therefore, making it usable.

I think I found something that could be part of the problem.
The glsl seems to be generated by varjo with format, so I did a little test as to what happens when many small blocks are put together with it.
(time (let ((text ""))
           (loop repeat 1000
                do (setq text (format nil "~A~D" text (random 100))))
           t))

characters     time
  1000          0.003
 10000          0.236
100000         17.766
200000        290.169

then it starts to get out of hand really quickly. I also tested with-output-to-string
(time (progn
        (with-output-to-string (stream)
          (loop repeat 1000 do (write (random 100) :stream stream)))
        t))

characters     time
    1000      0.000
   10000      0.002
  100000      0.014
 1000000      0.143
10000000      1.429

This seems to scale linearly.
Because my shaders are simply a really big list of switches, this explains why it takes so long to compile. Do you have some ideas about this?

If you could grant me access to the repo, or email me a zip of the whole project, I'd be happy to have a look and see where the time is going.

Sent you a google drive link.

@tsili Brilliant. And I have a solution. Your shader can be about 8 lines of lisp and doesnt need to be generated each time. I've been writing a little document as I did this so I could understand so I'll finish it and send it to you

But first I want to profile this big shader and see where Varjo is sucking...because man it is sucking :D

Hi again, @tsili I have the 1000 node version down to 0.45seconds & the 10000 node one down to 45seconds. There is still more to do but I'd like you to be able to try it. Please check out the feature/refactor-bindings branch and see if that helps you. I will run the test suite tomorrow and if this all looks good I'll get it merged in to master. Then I'l have to see what the next candidate for tuning is.
Thanks for your patience

Oh and remember to try flet instead of labels :)

I've merged the changes into master final time for 1000 node version was 0.3 seconds & for the 10000 21.7 seconds.
Of course these specific numbers are only on my machine, but the scale of the improvement relative to the original is what matters in this case

I'm also running some tests right now. The improvements are substantial. I just finished a test on 100 000 nodes in just 1.2 hours including not only the compilation of the model shader, but the construction of the node connections as well.
That is enough for me to only have one worker continuously churn out models. This would leave me with one thread for reading in data, one for compiling the models, one for managing the running model and a whopping nine threads to analyze the results these models give. With this setup I should be able to reduce the amount of GP-generations needed for the whole thesis as I will be able to compress multiple models into a single run and share the data and computing cycles between them and  make much better predictions on how to change the models for better performance.
Thank you so much.

My pleasure, thankyou for providing such good data to work with.
Whilst there are still performance issues to work on in general, I'm going to close this particular issue for now.
Feel free to open new issues if/when you find more perf problems (I expect similar issue for thousands of nested variable declarations) peace


[CONTINT-3744] Fill the repo_digests field in the SBOM payloads

What does this PR do?
Add a repo_digests field to the sbom message.
Motivation
The backend currently indexes the sboms by repo digests.
It currently has to look for it as a trivy-specific property inside the CycloneDX SBOM.
Having the field available in a dedicated field in SBOMPayload will make the process less dependent on potential future trivy changes.
Additional Notes
Requires DataDog/agent-payload#283.
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
The easiest way to validate that the new repo_digests field is properly filled is to configure the agent to send SBOM payloads to the fake intake and to inspect the payloads with fakeintakectl.
fakeintakectl --url http://… filter sbom --id ghcr.io/datadog/apps-nginx-server@sha256:de5c472beb90fb7b4726b1a56b15076b06f2857f8836ed4535f09ead70b37582

[
  {
    "type": 1,
    "id": "ghcr.io/datadog/apps-nginx-server@sha256:de5c472beb90fb7b4726b1a56b15076b06f2857f8836ed4535f09ead70b37582",
    "repo_tags": [
      "main"
    ],
    "inUse": true,
    "dd_tags": […],
    "Sbom": {…},
    "status": 1,
    "repo_digests": [
      "ghcr.io/datadog/apps-nginx-server@sha256:625f62fb6ebb306741285fbb600b62d9fa93a11215b9f3c9a51393b04913de2c"
    ]
  },

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

@clamoriniere :

@L3n41c do we have the same info already provided in the container_image payload?

Yes, we have exactly the same logic in the container_image check:
https://github.com/DataDog/datadog-agent/blob/8dd0bb27c88ac999d8f7b631e27fec204999a565/pkg/collector/corechecks/containerimage/processor.go#L139-L144
https://github.com/DataDog/datadog-agent/blob/8dd0bb27c88ac999d8f7b631e27fec204999a565/pkg/collector/corechecks/containerimage/processor.go#L175

/merge


load two images and swap between both with one button

where to find simple quickstart-example for such an job, i mean i tried but didn't find minimal example for it.

Here's an example:
https://codepen.io/iangilman/pen/erjyBP
...and one with fading:
https://codepen.io/iangilman/pen/YXRLea

thanks


Feature / help: Change app page from index.html to app.html

I'm submitting a ...
[ ] bug report
[v] feature request
[ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?
feature

What is the current behavior?
currently the entry point for the app is index.html I am trying to change it so index.html is a static page and app.html is the angular page.

I changed in webpack.dev.js the historyApiFallback to
historyApiFallback: {         index: '/app.html/'       },
and added to webpack.common.js
exclude: [helpers.root('src/app.html'), helpers.root('src/index.html')]
so the dev server serves the files from app.html. I still can't get it to serve the static index.html page.
Also when building, index.html is being created, and not app.html
help please?

anybody?


Update grpc-netty-shaded to 1.41.1

Updates io.grpc:grpc-netty-shaded from 1.41.0 to 1.41.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.grpc", artifactId = "grpc-netty-shaded" } ]

labels: library-update, early-semver-patch, semver-spec-patch

Superseded by #259.


Fix race conditions between tests in the processor test

Coverage increased (+0.2%) to 77.114% when pulling 24aa5bf692a1e7ca7060fb1b931da3ca6def331d on jmedved:contiv-crd into b0ae92d355a7adacb6f56f25116a017e72b55c69 on contiv:contiv-crd.


Analyses styling

Hi @Bioforest-project/data-preparation ,
As a test for a first issue/discussion, I wanted to discuss the fact that we want or not to include common styling to all the analyses. For instance, I'm using the tidyverse styling in most of my analyses (https://style.tidyverse.org/), but this could be another one.
And to make the discussion concrete, the styling concerns even the repository naming, and I'm not a fan of DataAgr_Species and DataAgr_inventories. First it is not consistent between the two and I think the DataAgr is superfluous. Second it's mixing several conventions as DatAgr is camel case writing (https://en.wikipedia.org/wiki/Camel_case), whereas agr_inventories is snake case writing (https://fr.wikipedia.org/wiki/Snake_case). I'm more fond of snake case but it can be discussed, I think it's only important that we are consistent. I would suggest only inventories and species but this could also be inventories_data and species_data, or something else, in which case we need also to be consistent with environment.
Sorry if this discussion seems superfluous, but I thought it could be a first good case of using GitHub issues to interact in the project.
Best,
Sylvain

I agree it is important to be consistent. I am ok with both Camel or Snale case, whatever is comfortable for the majority

Hi @Bioforest-project/data-preparation ,
As a test for a first issue/discussion, I wanted to discuss the fact that we want or not to include common styling to all the analyses. For instance, I'm using the tidyverse styling in most of my analyses (https://style.tidyverse.org/), but this could be another one.
And to make the discussion concrete, the styling concerns even the repository naming, and I'm not a fan of DataAgr_Species and DataAgr_inventories. First it is not consistent between the two and I think the DataAgr is superfluous. Second it's mixing several conventions as DatAgr is camel case writing (https://en.wikipedia.org/wiki/Camel_case), whereas agr_inventories is snake case writing (https://fr.wikipedia.org/wiki/Snake_case). I'm more fond of snake case but it can be discussed, I think it's only important that we are consistent. I would suggest only inventories and species but this could also be inventories_data and species_data, or something else, in which case we need also to be consistent with environment.
Sorry if this discussion seems superfluous, but I thought it could be a first good case of using GitHub issues to interact in the project.
Best,
Sylvain

I agree it is important to be consistent. I am ok with both Camel or Snake case, whatever is comfortable for the majority

Ok let's vote then:

I agree with the need to be consistent, even if in reality I'm deeply inconsistent, including with myself ;-) ! I'm fine with any convention and I will try my best to respect it. So let's decide what we want to do and I'll change the names of the repos I've created accordingly.

According to today's meeting we will use snake_case with lintr and styler but we need to make a clear doc and I'll be happy to debug if needed. In case this slow us down too much we will drop it.

I learnt a lot during this meeting, which lasted over an hour and a half. Now that we've agreed on these choices, all that's left for me to do is document them so that Sylvain doen't have to do too much to debug my scripts. Thanks everyone for making our task so much easier  :-)

According to today's meeting we will use snake_case with lintr and styler but we need to make a clear doc and I'll be happy to debug if needed. In case this slow us down too much we will drop it.

lintr and styler are in place. The contribution guidelines might me developed here regarding their usage: https://github.com/Bioforest-project/data_preparation/blob/391486fc0d3fc7145de25696dd6bfa8b60b0ff41/98_contributing.qmd#L75 . However, I'm considering the issue closed for now. Do not hesitate to reopen it if you feel necessary.

@sylvainschmitt @cpiponiot I'm discovering the jou of lintr. I have the impression I'm going to love this...
I manage to understand the style errors but what it this error 31? Do you know where to find a list of lintr errors?

If it's sarcastic know it can be difficult in the beginning but it goes very very quickly easier when you got used to it!
The line 31 is related to the GitHub action and you can ignore it. Basically lintr is throwing warnings and the warnings are converted in an error for the action to fail.
Your errors 23-28 are super simple and styler would clean them automatically, simply use styler::style_dir() in your project and it will clean them for you. The errors 29-30 should not exist because they are specific to R packages and I will inactivate them. Last but not least, if you do not want to correct some errors you can simply use the #nolint comment at the end of the line, but do not abuse of it. Typically if your line of 271 character is due to a string you don't want to break.

If it's sarcastic know it can be difficult in the beginning but it goes very very quickly easier when you got used to it!
The line 31 is related to the GitHub action and you can ignore it. Basically lintr is throwing warnings and the warnings are converted in an error for the action to fail.
Your errors 23-28 are super simple and styler would clean them automatically, simply use styler::style_dir() in your project and it will clean them for you. The errors 29-30 should not exist because they are specific to R packages and I will inactivate them. Last but not least, if you do not want to correct some errors you can simply use the #nolint comment at the end of the line, but do not abuse of it. Typically if your line of 271 character is due to a string you don't want to break.

@sylvainschmitt Thanks for your answer ! Yes it was sarcastic... but I do totally see the point of it, and also I agree that most of the error are easy to correct, I did it manually but I will use styler from now on.

@GeraldineDerroire , it can be indeed very time consuming and rebarbative to correct some manually (e.g. trailing spaces). I could totally add a call to styler::style_dir() in the GitHub action. Then you would have only to pull back to get your code cleaned after a push. However, there is a risk to create more conflict has it is not immediate.

@GeraldineDerroire , it can be indeed very time consuming and rebarbative to correct some manually (e.g. trailing spaces). I could totally add a call to styler::style_dir() in the GitHub action. Then you would have only to pull back to get your code cleaned after a push. However, there is a risk to create more conflict has it is not immediate.

No worries, all good. I've ran styler::style_dir() before pushing and it corrected almost everything. I know how to correct the things not automatically corrected, they are very basic. I will do it (but maybe not at every push).
One thing though, I add to install styler. You didn't put it in the renv when you set the repo?

@mithilaunkule , beware the left attribution '->" are not in compliance with our style. I'm adding lintr and styler to the renv of the inventories project. Please use first styler::style_dir() and then lintr::lint_dir() before pushing to ensure the style of your code. Sorry for spotting you, you are certainly not the only one. But it's better to alert early than cleaning when the code is very long.


pull request for e2e test at 01/27/2017 19:15:17

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Remove the magic value 'max_connections=32'

Remove the magic value 'max_connections=32' in client.py,using None as default.
If we do not set 'max_connections', it is easy to throw out the exception "Too many connections".

@leeglezhao Please do not open and close the same PR

@leeglezhao I am not sure i get why you want this merged, could you elaborate some more why this should be changed to None. A use-case, a reason, an example or similar.


Bad Checksum

When 5th client joins the server, then this error coming on client side.
Exception: bad checksum
Fossil.Delta.Apply (System.Byte[] origin, System.Byte[] delta) (at Assets/Plugins/FossilDelta/Delta.cs:204)
Colyseus.Room.Patch (System.Byte[] delta) (at Assets/Plugins/Colyseus/Room.cs:173)
Colyseus.Room.ParseMessage (System.Byte[] recv) (at Assets/Plugins/Colyseus/Room.cs:163)
Colyseus.Room.Recv () (at Assets/Plugins/Colyseus/Room.cs:73)
Colyseus.Client.Recv () (at Assets/Plugins/Colyseus/Client.cs:88)
ColyseusClient+<Start>c__Iterator0.MoveNext () (at Assets/ColyseusClient.cs:40)
UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) (at C:/buildslave/unity/build/Runtime/Export/Coroutines.cs:17)

After this error, 5th client not getting any messages from server.

Thanks for reporting @sagestudios. I just confirmed exactly what you described in the example project. I'll have a look into that.
How's been your experience so far with the framework? Cheers!

Hello Endel, loved the framework :) . Exactly what we are looking for in terms of features. Porting our current games will be easy. Have to test the performance and scalability. Looking forward for horizontal scaling in upcoming versions.


(mnt) bump number

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Since I used 1 for adding you, I think we need to bump to 2 so that the artifacts go live with _2 extension

You do need to re-render when adding a maintainer, though.


How to create a EGraph from IFeature

I am using the nuget package on my project.
So far from my shapefile I get IFeatures which are polygons.
string fileName = "xxxx.shp";
            string path = Path.Combine(Environment.CurrentDirectory, @"wwwroot\files\xPolygons\", fileName);
            Shapefile importedShapeFile = Shapefile.OpenFile(path);

            for (int i = 0; i < importedShapeFile.DataTable.Rows.Count; i++)
            {

                // Get the feature
                IFeature feature = importedShapeFile.Features.ElementAt(i);

                DotSpatial.Topology.IGeometry geometry = (Geometry)feature.BasicGeometry;

//Have to convert it GeoApi Geometry but Idk how??
            }

how can I create a egraph by using EGraph graph = EdgeGraphBuilder.Build(geometry);

No idea what an EGraph is, so no idea how to create it.
But your comment says that you need a GeoAPI Geometry and you don't know how to convert to it.
This we can answer by using DotSpatial 2.0 instead of the version you're currently using. There we use DotSpatial.GeoAPI instaed of DotSpatial.Topology.

@jany-tenaj Thank you for your quick reply.
https://github.com/DotSpatial/NetTopologySuite/blob/ds_master/NetTopologySuite/EdgeGraph/EdgeGraphBuilder.cs
Requires GeoAPI List to create the edge graph but there is no way to convert to that I guess.
When DotSpatial 2.0 will be available? It says latest version is 1.9 right now and there is no future versioning info.

I think this is at 2.0 https://ci.appveyor.com/api/projects/mogikanin/dotspatial/artifacts/Source/bin/Release.zip?branch=master

@sindizzy Thank you!
Any nuget package available for 2.0?

I added pre release from nuget. and receiving following error.
The type 'IGeometry' is defined in an assembly that is not referenced. You must add a reference to assembly 'DotSpatial.GeoAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=a1a0da7def465678'.
There is no DotSpatial.GeoAPI, Version=<IP_ADDRESS>, :)
History record from nuget :)
<IP_ADDRESS> (current) | 4.722 | 15.12.2016
<IP_ADDRESS> | 1.925 | 24.05.2016
<IP_ADDRESS> | 2.512 | 10.05.2016


Visual C++ Build Tools not detected

Visual C++ Build Tools preview can be downloaded from http://go.microsoft.com/fwlink/?LinkId=691132
This is a standalone compiler without the Visual Studio IDE. Tundra does not detect that this is installed.

That's probably because they way we detect a Visual Studio toolchain is very different from the way this bundle from Microsoft works.
Would you mind doing some leg work? We need to know what folder structure Microsoft is using for this release and how it relates to any SDK.

That is indeed what is happening. I did attempt to find a nice way to detect the presence of the Build Tools, but wasn’t able to find anything that is guaranteed to work. I gave up after that and moved back to the regular Visual Studio installs, so this issue isn’t pressing. I’m willing to take a look again at some point though.
Cheers,
Rick

On 13 Jan 2016, at 10:35, John Leidegren<EMAIL_ADDRESS>wrote:
That's probably because they way we detect a Visual Studio toolchain is very different from the way this bundle from Microsoft works.
Would you mind doing some leg work? We need to know what folder structure Microsoft is using for this release and how it relates to any SDK.
—
Reply to this email directly or view it on GitHub https://github.com/deplinenoise/tundra/issues/272#issuecomment-171230629.

Closed as part of e07b12ac87bcc3f17d1d7e3e0c2c96c8bb3815af


Hikvision Binary Sensor

Hello,
I tried to use the binary Sensor with my Hikvison TV-IP311PI Camera but there no Sensor added after a reboot. In the log I can‘t find anythimg about the Hikvison Sensor. The Camera Configuration is like the right.

Not all Hikvision cameras as supported. It is possible that your camera is not supported.

Yes I know @arsaboo but I think the Firmware is almost the same so there is maybe a way to use my Cams. The ffmpeg Motion Sensor isn‘t that great.

If your camera is not listed, please open an issue on the parent library https://github.com/mezz64/pyHik and close this issue.

Your posted model # looks like it's for a Trendnet camera, not a Hikvision.  Even if it's rebadged it's very likely the firmware is changed enough to not comply with the api.


backend-client: Fix image retrival and edit

Description
This PR add necessary parameters to the request, code changes to accept new request, necessary documentation change, some indentation fixes as well.
This PR fixes the issue of not able to edit images as well.
Fixes #624
Type of change

[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 not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] npm test
[x] flask test

Test Configuration:

OS version: Ubuntu 20.04
Python 3.8

Also, include screenshots of app for the verification and reviewing purpose.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

@amlannandy Please find the link to demo of working https://drive.google.com/file/d/1y3HuQmHTFpCRirGh26EVUd1qg0dnxCE6/view?usp=sharing

Nice work 👍🏻


Doesn't scroll properly inside ViewPager

I'm trying to use CompactCalendarView on the fragment inside ViewPager.
CompactCalendarView control doesn't scroll properly - ViewPager scrolls instead of calendar.

Have a look at this issue #39, because it might be related. I believe someone implemented some fix for it, I have not yet tested things out with viewpager, but there might be some conflict between ontouch events being consumed by viewpager and not making it to the calendar.

Thank you for such a quick response!
You are absolutely right about conflict with viewpager on touch events.
I fixed the issue for myself just extending your control and overriding onTouchEvent
Also, I filed the pull request for you with this fix. Please consider it.
P.S.
Thank you for such a good control. I'll use it in my pet project.

Merged to master, will apply my changes for the sample project that includes the calendar inside a viewpager.

Just an update, I updated the main sample app to use a viewpager as an example to prove that this works. I can see my unit tests pass, so I will release a new version sometime today/tomorrow after I merge those changes to master.

Released under:
dependencies {
    compile 'com.github.sundeepk:compact-calendar-view:1.8.5'
}


Updating country lvl aggregate to output yearly metrics for pct and number of ius with Xpct of runs reaching a threshold.

As per this issue: https://github.com/NTD-Modelling-Consortium/endgame-project/issues/145, updating the pct_of_ius_passing_Xpct_under_threshold and count_of_ius_passing_Xpct_under_threshold measures to be output yearly.
Note:
Tests need to be updated

The results look correct (please check in the updated LKG file - that's the point of running it with the update).

This fixes https://github.com/NTD-Modelling-Consortium/endgame-project/issues/145

Just an FYI: I added another commit to change the order of the columns in the two tests in test_aggregation.py that are failing, however it doesn't seem to be getting picked up in the CI.


[core] Synchronizer handles hashchain events

In #246 we add two hashchain events: HashchainBuilt and HashchainProcessed
These two events can be handled by synchronizer so that in the genAggregateEpochKeysProof it doesn't need to take the arguments like hashchainIndex(or set it as default value that can be queried from synchronizer db or contract)

Hey team! Please add your planning poker estimate with Zenhub @CJ-Rose @AnthonyMadia @0xChiali @kittybest @vivianjeng


React.forwardRef example

I'm trying to figure out the example for forwardRef'd component.

HeadingProps isn't used
There does not seem to be a type called React.ForwardedRef

Thanks for your feedback!
HeadingProps are exported as an example to follow conventions set by libraries. Each component’s corresponding prop types are made available alongside the component itself, e.g.:
import { Heading, HeadingProps } from "@/components/Heading";

React.ForwardedRef is available in a separate @react/types package (which is marked as a peer dependency).

Thanks for your feedback!
HeadingProps are exported as an example to follow conventions set by libraries. Each component’s corresponding prop types are made available alongside the component itself, e.g.:
import { Heading, HeadingProps } from "@/components/Heading";

React.ForwardedRef is available in a separate @react/types package (which is marked as a peer dependency).

Oh, I had types for React 16 installed. Thanks!

Oh, I had types for React 16 installed. Thanks!


Scala Stream Collector: add return path for collector cookie value

Three options:

POST to a new endpoint which returns a self-describing JSON containing the cookie
A special endpoint which redirects to a URL containing the cookie
The response to the existing POST requests (see also #2605)

I think I am leaning towards 1 as it is the most modular (it doesn't require the JavaScript Tracker to use; it doesn't require changes to be made to the trackers).

/cc @shermozle


New plugin: Scaleway

Build a new shell plugin for the Scaleway CLI.
Addresses: #189
Setup

Have a Scaleway account.
Install the Scaleway CLI.
Build and test the Scaleway plugin locally according to these instructions, i.e. make scaleway/build.

Importer

Create an Api Key.
Get your Scaleway Organization ID.
Initialize the Scaleway plugin:
a. By entering manually required information
b. From file by first initializing Scaleway cli, i.e. scw init, prior to Scaleway 1Password Shell plugin.

Provisioner
Once the Scaleway 1Password shell plugin initialized and the related ceredentials stored in 1Password, try to use the Scaleway cli tool via op plugin run -- scw or just scw if you have the adequate alias. Here an example of command you can try scw instance server-type list.

Hey @maxlareo , just following up on this! Is there any way we could help you move this forward?

Hi @maxlareo, any updates here? I would be happy to help remove any uncertainties and move this forward!

@maxlareo This has been in draft for a few months now, so I'll be closing it, for the time being.
Please do re-open if you want to resume your work, we'd love to help you move this forward!


Depth working?

Does the depth flag work as I'm expecting it to? If I watch directory '/tmp/ryan' and set a depth of 0 or 1, when files change in subdirectory /tmp/ryan/foo/bar, I'm still getting notifications. I just changed your default example in the Readme to include a depth for testing:
var chokidar = require('chokidar');

var watcher = chokidar.watch('/tmp/ryan', {ignored: /[\/\\]\./, persistent: true, depth: 1});

watcher
  .on('add', function(path) {console.log('File', path, 'has been added');})
  .on('addDir', function(path) {console.log('Directory', path, 'has been added');})
  .on('change', function(path) {console.log('File', path, 'has been changed');})
  .on('unlink', function(path) {console.log('File', path, 'has been removed');})
  .on('unlinkDir', function(path) {console.log('Directory', path, 'has been removed');})
  .on('error', function(error) {console.error('Error happened', error);})
  .on('ready', function() {console.info('Initial scan complete. Ready for changes.')})
  .on('raw', function(event, path, details) {console.info('Raw event info:', event, path, details)})

The depth feature has not been published yet. You'd need to install the git master branch version of the module to use it prior to the upcoming 1.0 release: npm i paulmillr/chokidar

Ah, I've just been wondering why depth didn't work. Hopefully we'll see it released soon!
@es128 Could you clarify if a depth of 0 or 1 means it does not recurse?

0

Setting depth: 0 for watching a folder should not watch for files added to subdirectories. However this only works for the initial scan. If subdirectories are created and files added to the watched folder after the initial scan, they will be reported nonetheless. Is this a bug?
this._watch = chokidar.watch(what, { depth: 0, ignored: /(^|[\/\\])\../ });
this._watch.on("add", path => console.log("new file", path));


ERROR: Condition "font.is_null()" is true at: _shape (scene/gui/line_edit.cpp:2202) on project open

Godot version
v4.0.beta.custom_build [99bc4905c]
System information
Linux Ubuntu 20.04 with Unity desktop
Issue description
On project launch (new project creation or open project), I have an error:
ERROR: Condition "font.is_null()" is true.
   at: _shape (scene/gui/line_edit.cpp:2202)

The error occurs in v4.0.beta.custom_build [99bc4905c], but doesn't occur on v3.4.1.stable.official [aa1b95889] (I didn't test v3.5.1 stable).
Steps to reproduce
Open Godot and either create a new project or open an existing one.
Minimal reproduction project
No response

Seems like EventListenerLineEdit subclass is setting placeholder in the constructor, before font is set or theme is initialized.

Pinning the issue as users will encounter it in 4.0 beta 3 (it's fixed in master and thus will be fixed in 4.0 beta 4).

I did not realise it was my changes that caused this! Apologies.


QueryBuilder set() depend call-order when the same column is used at 'where'

before fixing it, placeholders are duplicated.
This occers just when calling the order: where() -> set().
There is no probrem at set() -> where().
$ phpunit tests/system/Database/Builder/UpdateTest.php

==== Redirecting to composer installed version in vendor/phpunit ====

PHPUnit 5.3.5 by Sebastian Bergmann and contributors.

..........F                                                       11 / 11 (100%)

Time: 45 ms, Memory: 4.00MB

There was 1 failure:

1) CodeIgniter\Database\Builder\UpdateTest::testUpdateWithWhereSameColumn3
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'UPDATE "jobs" SET "name" = :name0 WHERE "name" = :name'
+'UPDATE "jobs" SET "name" = :name WHERE "name" = :name'

/path/to/project/tests/system/Database/Builder/UpdateTest.php:194

FAILURES!
Tests: 11, Assertions: 22, Failures: 1.

I wasn’t aware of that. I add it and test against mariadb.
I will setup postgresql soon.

Looks good. All tests passed against both MySQL and Postgres on Travis so we are good to go. Thanks!


Alpha 01 API review

we should go through existing public APIs and make sure we are not opening up stuff that we don't intend do, make sure documentation is there, understandable etc.
Porbably an easy way to do this is to build docs and read :)

closed by #56


Forwardport: Custom search filter for openldap and freeipa

Forwardport https://github.com/rancher/rancher/issues/18630

Tested with master-head build (b19342add855)
Enabled OPEN LDAP auth: "Search Filter" field option is presented for User and Groups in "Customize Schema" section.
Users have the option to set these fields when OpenLdap auth is enabled. When the field is set , this filter gets applied to the list of users/groups that get searched when adding users to add members to cluster/projects.
The following tests were done:
User Search Filter
(memberOf=cn=abcd,ou=groups,dc=us-west,dc=xxx,dc=xxx) - It returned the users testuser1,testuser2,testuser3 as expected


React component creation practice project for simple calculator.

In this project :-

I have continued the development of the Math Magicians app
I develop a React component that will hold the core functionality of a calculator
Thank you for reviewing my project !!!!.

okay, Thanks I will update it soon.

kindly, am repeating the module so there is no need to redo the task that are already approved. so please approve it.


Exemptions

Hello, just a quick question regarding these policies.
They seem like a really good starting-point for an eventual native PSP re-implementation.
Currently we are using Gatekeeper, with all of the webhook-related fun that brings.
I would like to ask, are you planning on adding exemption configuration to the rules?
We have forked gatekeeper-library in order to extend exemptions to namespace/image (instead of just image path).
It would be great to see similar exemptions be allowed per rule on this project.
This project could be the starting-point for defacto secure policy on k8s, well done.

Hey, @technotaff-nbs !
Yes, we were talking about what we call "ignore rules" implementation. I guess it is essentially the same as the exemption configuration you have mentioned.
We have been thinking about two approaches:

Annotate objects with "ignore" directives for specific rules (eg. do not apply C-0012 to this Deployment)
Create CRs that are able to describe "ignore" cases (eg. C-0012 and an object that match the rule namespace==test should be ignored)

We'd really love to hear more about how you see this and how would you like to describe your exemptions.
I think we will start to work on it in the second part of the summer, any user input is gold for us right now.
Thx
B


Add contact APIs of razorpayX

SDK doesn't implement contact APIs from razorpaX

@atishabhang Sorry for the delay. As of now the SDK is not supporting razorpay-x api's. i will discuss this to integration team to add this to our roadmap , we will let you know in this issue whenever it released.


Add Hipchat emoji pack

Went ahead and wrote a little YAML file for Hipchat emojis based on this page: https://www.hipchat.com/emoticons
hipchat.yaml

jk, that file doesn't work (indenting issues).
hipchat.yaml.txt

Is this different from https://raw.githubusercontent.com/lambtron/emojipacks/master/packs/hipchat.yaml referenced in the readme?

Ah, true dat, not different. JK :)