p4wq has a race with work item re-use

The p4wq code, to handle the case where a work item was re-submitted, needs to inspect the thread field of the work item after the user callback has returned.  But this will race with the case where the user code needs to (in some other context, on some other CPU) re-use that work item (for example by freeing it into the heap, or filling it out again for resubmission).
In the case where the item was not resubmitted, the p4wq code must never touch the memory of a work item after its callback has returned.
(In practice, we just need one bit for "was resubmitted", which we can track per-thread somewhere I guess.  Needs a little thought, but shouldn't be difficult.)

Race found by @lyakh while investigating #29623


Tracking issues of OpenDAL v0.49.0 Release

This issue is used to track tasks of the opendal ${opendal_version} release.
Tasks
Blockers

[ ] https://github.com/apache/opendal/pull/4978
[x] https://github.com/apache/opendal/pull/4980
[ ] https://github.com/apache/opendal/pull/4961

Build Release
Release List

Name
Version
Next

core
0.48.0
0.49.0

integrations/dav-server
0.0.6
0.0.7

integrations/fuse3
0.0.3
0.0.4

integrations/object_store
0.45.0
0.46.0

integrations/parquet
0.0.1
0.1.0

integrations/unftp-sbe
0.0.3
0.0.4

bin/oay
0.41.7
0.41.8

bin/ofs
0.0.8
0.0.9

bin/oli
0.41.7
0.41.8

bindings/c
0.44.9
0.44.10

bindings/cpp
0.45.7
0.45.8

bindings/dotnet
0.1.5
0.1.6

bindings/go
0.0.0
0.1.0

bindings/haskell
0.44.7
0.44.8

bindings/java
0.46.4
0.47.0

bindings/lua
0.1.5
0.1.6

bindings/nodejs
0.47.1
0.47.2

bindings/php
0.1.5
0.1.6

bindings/python
0.45.7
0.45.8

bindings/ruby
0.1.5
0.1.6

GitHub Side

[ ] Bump version in project

[ ] rust
[ ] cpp
[ ] haskell
[ ] java
[ ] nodejs

[ ] Update docs
[ ] Generate dependencies list
[ ] Push release candidate tag to GitHub

ASF Side

[ ] Create an ASF Release
[ ] Upload artifacts to the SVN dist repo
[ ] Close the Nexus staging repo

Voting

[ ] Start VOTE at opendal community

Official Release

[ ] Push the release git tag
[ ] Publish artifacts to SVN RELEASE branch
[ ] Release Maven artifacts
[ ] Send the announcement

For details of each step, please refer to: https://opendal.apache.org/community/release/

https://github.com/apache/opendal/pull/4978 is not a breaking change, so we can release it even if it isn't completed yet. We can include it in our next patch release.


Fill with mock doesn't work ?

Hello,
Since the last version the 'fill with mock' functionality doesn't work. I only have 'Fill current parameter with mock'
This is regratable when I have multiple dependency injection.
My setup is
Resharper 2020.2.4
VS 2019 (16.7.6)
Xunit

My bad in a tiny project it's working

What can I do in a bigger one ?

Can you please share a solution with the issue, so that I can investigate?
Or, give your full classes signature.

@paudebert any news on the above?
You might have this behavior because your constructor have parameters that are not interface nor abstract classes

Closing this as no answer. Please reopen if needed

Closing this as no answer. Please reopen if needed


Blue Model with Relay on PCB - Cannot set clock

Here it is my model:

Now 1F:7F disappeared and I have 00:00 but I cannot set the clock, Display show temp in °C but It's showing Light Sensor data infact If I go dark in the room it shows 54-55°C, with neon light temp show variables value from 18° to 26° (it's reading light and showing as temp eheh)
Maybe also all DS1302 pins needs to be set to bidirectional.
Thanks for helping

You are my hero!!!!!! Finally it's working perfectly with your shining firmware :))))
I've configured global.h this way:
#define BOARD_TALKING      FALSE
#define BOARD_BLUE_6       FALSE
#define BOARD_BLUE_5_RELAY TRUE
#define BOARD_YELLOW_5     FALSE
#define BOARD_YELLOW_SMALL FALSE
#define BOARD_WHITE_SMALL  FALSE
#define BOARD_GREEN_SMALL  FALSE
#define COMMON_ANODE   TRUE
#define COMMON_CATHODE FALSE
#define PROC_IS_15W408AS FALSE
#define PROC_IS_15W404AS FALSE
#define PROC_IS_15F204EA TRUE
#define HAS_LDR TRUE
#define HAS_THERMISTOR TRUE
#define HAS_RELAY TRUE
#define DIGIT_3_FLIP TRUE
And finally look here:

and here:

Thanks thanks thanks

Please be sure to rebuild with the main.c file that shows as "Merge pull request #5 from Metori/chime_hours_fix". Another user was kind enough to fix a bug in the chime code that I merged after I posted the fix for the 15F204EA processor type. :relieved:


Join forks code into (this) main repo

There are currently 2 forks of SFZero which provide useful new features.
https://github.com/schellingb/SFZero
https://github.com/jamiebullock/SFZero
Would be nice to get everything together in 1 repo, so we don't have to choose between features.
I would rather submit bugs against the forks, to request a PR from them, but they have closed the reporting of bugs :(

Will you accept a PR that incorporates the useful changes from those repos?
I could do this, eventually...

It might be useful to ping @schellingb and @jamiebullock for this?

@falkTX @simonvanderveldt Sorry, I've only just seen this, for some reason I missed the notification.
I think merging forks would be a good idea, but it needs some care. I'm also not sure if @stevefolta is interested in continuing to work on this, review and merge PRs etc. It might be better if one of the downstream repos became the official one.
Anyhow, I've opened the issue tracker on my fork if you want to report bugs there.


Column overrun on ADJ file

On erroneous output in some columns, the data overruns into the next columns. This makes it extremely difficult in automatically parsing results. Can you truncate these before output, possibly go to scientific if it breaches 0 decimal places?
The adjustment sd is so large it runs into the residual columns when I parse the columns using the specified column details in the manual I get
240009879.931 and<PHONE_NUMBER>.9310
rather than the actual
240009879.9312 and<PHONE_NUMBER>.9310

Please see attached adj file, I had to change it to text to upload.
TP325001Y.simult.txt

TP325001Y.stn.txt
TP325001Y.msr.txt

Just tested the v1.1.0 release on data with adjustment issues, and it appears that not all the columns have had their overflows fixed - see below ADJ file, in particular "adjusted" and/or "correction" columns.
690d1ab601ca44f18ec5e08bf1a1858c.phased.adj.txt
Further to this, the result in the COR file are also still overflowing - see below.
690d1ab601ca44f18ec5e08bf1a1858c.phased.cor.txt
Is it possible for the fixed to be applied to all columns in all files? Our parsing priorities are the ADJ file, APU file, and COR file.
Full input data and adjustment params:
PS527037N.zip


How sign in/up with Facebook

I have 3 app.
Meteor = api.example.com
Web = example.com
Mobile = mobile.example.com
How do I configure XX to redirect to WEB or MOBILE as the case may be?
i follow https://angular-meteor.com/tutorials/whatsapp2/ionic/facebook but i cant setup to 3 diferents subdomains.
Thanks.

See #77

@ardatan  this dont work for me example.
@Urigo  can u help me please?
Thanks

@katusiky Can you give more details?

@ardatan I need login with facebook from my client.
when i try login from client, facebook automatically redirect to server subdomain and never redirect again to client.
i cant create nginx config to 3 differents subdomains.


Bus error

Hi,
$ zpaqfranz
zpaqfranz v58.10o-NOJIT-L(2023-10-01)

$ sw_vers
ProductName:		macOS
ProductVersion:		14.1
BuildVersion:		23B5067a

Mac Mini 2020 M1 - 16GB RAM

I am occasionally getting these crash reports from zpaqfranz - "Bus Error". Looks like it's crashing in a simple printf function? Is there any way to debug this further?
Here's the most recent crash report:
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               zpaqfranz [19354]
Path:                  /opt/homebrew/*/zpaqfranz
Identifier:            zpaqfranz
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        bash [19338]
Responsible:           bash [19221]
User ID:               501

Date/Time:             2023-10-17 23:36:45.4675 -0400
OS Version:            macOS 14.1 (23B5067a)
Report Version:        12
Anonymous UUID:        A6DF521A-3508-6D9A-A2C2-BF0317E32BFC

Time Awake Since Boot: 470000 seconds

System Integrity Protection: enabled

Crashed Thread:        2

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x000000016daf3f58
Exception Codes:       0x0000000000000002, 0x000000016daf3f58

Termination Reason:    Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process:   exc handler [19354]

VM Region Info: 0x16daf3f58 is in 0x16daf0000-0x16daf4000;  bytes after start: 16216  bytes before end: 167
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      Stack                       16da68000-16daf0000    [  544K] rw-/rwx SM=PRV  thread 1
--->  STACK GUARD                 16daf0000-16daf4000    [   16K] ---/rwx SM=NUL  ... for thread 2
      Stack                       16daf4000-16db7c000    [  544K] rw-/rwx SM=PRV  thread 2

Thread 0::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x18b4fe66c __ulock_wait + 8
1   libsystem_pthread.dylib       	       0x18b53f49c _pthread_join + 608
2   zpaqfranz                     	       0x10242f110 Jidac::verify(bool) + 2960
3   zpaqfranz                     	       0x102406610 Jidac::add() + 41792
4   zpaqfranz                     	       0x10244cd2c main + 444
5   dyld                          	       0x18b1c10e0 start + 2360

Thread 1:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b3e1ab8 __fread + 256
5   libsystem_c.dylib             	       0x18b3ea178 fread + 64
6   zpaqfranz                     	       0x102441914 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 1580
7   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
8   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 2 Crashed:
0   libsystem_c.dylib             	       0x18b3d7f84 __vfprintf + 60
1   libsystem_c.dylib             	       0x18b4027c4 _vsnprintf + 224
2   zpaqfranz                     	       0x1023b3a24 myprintf(char const*, ...) + 84
3   zpaqfranz                     	       0x1023e093c myavanzamentoby1sec(long long, long long, long long, bool) + 676
4   zpaqfranz                     	       0x102441b18 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 2096
5   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
6   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
7   libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 3:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b3e1ab8 __fread + 256
5   libsystem_c.dylib             	       0x18b3ea178 fread + 64
6   zpaqfranz                     	       0x102441914 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 1580
7   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
8   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 4:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b4056ac _fseeko + 732
5   libsystem_c.dylib             	       0x18b3e9bec fseeko + 92
6   zpaqfranz                     	       0x1023be838 prendidimensionefile(char const*) + 40
7   zpaqfranz                     	       0x1024416a0 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 952
8   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
9   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 5:
0   libsystem_kernel.dylib        	       0x18b4fd4a0 __open_nocancel + 8
1   libsystem_kernel.dylib        	       0x18b5109f0 open$NOCANCEL + 64
2   libsystem_c.dylib             	       0x18b3e5d00 fopen + 92
3   zpaqfranz                     	       0x1023be770 freadopen(char const*) + 28
4   zpaqfranz                     	       0x102441680 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 920
5   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
6   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
7   libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 6:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b4056ac _fseeko + 732
5   libsystem_c.dylib             	       0x18b3e9bec fseeko + 92
6   zpaqfranz                     	       0x1023be838 prendidimensionefile(char const*) + 40
7   zpaqfranz                     	       0x1024416a0 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 952
8   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
9   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 7:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b4056ac _fseeko + 732
5   libsystem_c.dylib             	       0x18b3e9bec fseeko + 92
6   zpaqfranz                     	       0x1023be838 prendidimensionefile(char const*) + 40
7   zpaqfranz                     	       0x1024416a0 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 952
8   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
9   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 8:
0   libsystem_kernel.dylib        	       0x18b4fe820 __read_nocancel + 8
1   libsystem_c.dylib             	       0x18b403744 __sread + 24
2   libsystem_c.dylib             	       0x18b3e1964 _sread + 32
3   libsystem_c.dylib             	       0x18b3e18f8 __srefill1 + 36
4   libsystem_c.dylib             	       0x18b3e1ab8 __fread + 256
5   libsystem_c.dylib             	       0x18b3ea178 fread + 64
6   zpaqfranz                     	       0x102441914 franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long) + 1580
7   zpaqfranz                     	       0x102449eb4 scansionahash(void*) + 272
8   libsystem_pthread.dylib       	       0x18b53d034 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b537e3c thread_start + 8

Thread 2 crashed with ARM Thread State (64-bit):
    x0: 0x000000016daf4128   x1: 0x00000001e16ec6b8   x2: 0x00000001024a4786   x3: 0x000000016daf5300
    x4: 0x00000001024a4786   x5: 0x000000016daf5300   x6: 0x000000016daf5300   x7: 0x000000010249ea79
    x8: 0x0dba0499489e0023   x9: 0x0dba0499489e0023  x10: 0x000000016daf42d8  x11: 0x00000000ffff0208
   x12: 0x000000000000002e  x13: 0xcccccccccccccccd  x14: 0x000000000000000a  x15: 0x00000000fffffff7
   x16: 0x000000029dc0684c  x17: 0x0000000000000000  x18: 0x0000000000000000  x19: 0x00000001e16ec6b8
   x20: 0x0000000000000001  x21: 0x00000000156319fb  x22: 0x000000002d4cbe9b  x23: 0x0000000000000001
   x24: 0x00000001024fcaf5  x25: 0x000000000000002f  x26: 0x0000000000000000  x27: 0x00000001024a4786
   x28: 0x0000000000000001   fp: 0x000000016daf4110   lr: 0xc57500018b4027c4
    sp: 0x000000016daf3d30   pc: 0x000000018b3d7f84 cpsr: 0x60001000
   far: 0x000000016daf3f58  esr: 0x92000047 (Data Abort) byte write Translation fault

Binary Images:
       0x10239c000 -        0x1024c3fff zpaqfranz (*) <23d7e721-8e5d-310e-b42b-f413028db4a7> /opt/homebrew/*/zpaqfranz
       0x18b4fb000 -        0x18b535fef libsystem_kernel.dylib (*) <8e284c01-80f9-3be7-b660-3cca3893bb20> /usr/lib/system/libsystem_kernel.dylib
       0x18b536000 -        0x18b542ff3 libsystem_pthread.dylib (*) <75288deb-6d30-3e42-8799-88302598394b> /usr/lib/system/libsystem_pthread.dylib
       0x18b1bb000 -        0x18b24f317 dyld (*) <9f091f00-ff69-358f-8d89-adf6bccf8422> /usr/lib/dyld
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x18b3d6000 -        0x18b454ffb libsystem_c.dylib (*) <253bbb56-ff67-3189-b5c1-d651e35322cf> /usr/lib/system/libsystem_c.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=893.2M resident=0K(0%) swapped_out_or_unallocated=893.2M(100%)
Writable regions: Total=1.6G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=1.6G(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Kernel Alloc Once                   32K        1
MALLOC                             1.6G       53
MALLOC guard page                   96K        6
STACK GUARD                       56.1M        9
Stack                             12.2M        9
__AUTH                              46K       12
__AUTH_CONST                        76K       39
__DATA                             417K       40
__DATA_CONST                       203K       41
__DATA_DIRTY                        79K       22
__LINKEDIT                       886.7M        2
__OBJC_RO                         70.8M        1
__OBJC_RW                         2156K        1
__TEXT                            6640K       43
dyld private memory                272K        2
shared memory                       80K        4
===========                     =======  =======
TOTAL                              2.6G      285

-----------
Full Report
-----------

{"app_name":"zpaqfranz","timestamp":"2023-10-17 23:36:45.00 -0400","app_version":"","slice_uuid":"23d7e721-8e5d-310e-b42b-f413028db4a7","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 14.1 (23B5067a)","roots_installed":0,"incident_id":"B3760B41-1E27-4D32-ACD9-A1F0A20CAF69","name":"zpaqfranz"}
{
  "uptime" : 470000,
  "procRole" : "Unspecified",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "Macmini9,1",
  "coalitionID" : 3592,
  "osVersion" : {
    "train" : "macOS 14.1",
    "build" : "23B5067a",
    "releaseType" : "User"
  },
  "captureTime" : "2023-10-17 23:36:45.4675 -0400",
  "codeSigningMonitor" : 1,
  "incident" : "B3760B41-1E27-4D32-ACD9-A1F0A20CAF69",
  "pid" : 19354,
  "translated" : false,
  "cpuType" : "ARM-64",
  "roots_installed" : 0,
  "bug_type" : "309",
  "procLaunch" : "2023-10-17 23:36:40.9818 -0400",
  "procStartAbsTime" :<PHONE_NUMBER>2709,
  "procExitAbsTime" :<PHONE_NUMBER>9225,
  "procName" : "zpaqfranz",
  "procPath" : "\/opt\/homebrew\/*\/zpaqfranz",
  "parentProc" : "bash",
  "parentPid" : 19338,
  "coalitionName" : "com.ldh.periodic-1h.agent",
  "crashReporterKey" : "A6DF521A-3508-6D9A-A2C2-BF0317E32BFC",
  "responsiblePid" : 19221,
  "responsibleProc" : "bash",
  "codeSigningID" : "zpaqfranz",
  "codeSigningTeamID" : "",
  "codeSigningFlags" : 570556929,
  "codeSigningValidationCategory" : 10,
  "codeSigningTrustLevel" :<PHONE_NUMBER>,
  "instructionByteStream" : {"beforePC":"9E8Eqf17Ban9QwGR\/0MO0fsDAqrzAwGqyBgrkAihB5EIAUD5qIMZ+A==","atPC":"4xcB+f+fCDnpgwSR\/wsB+QDkAG8ggQat\/+8Buf\/zAPn\/3wG5\/\/8cqQ=="},
  "sip" : "enabled",
  "vmRegionInfo" : "0x16daf3f58 is in 0x16daf0000-0x16daf4000;  bytes after start: 16216  bytes before end: 167\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      Stack                       16da68000-16daf0000    [  544K] rw-\/rwx SM=PRV  thread 1\n--->  STACK GUARD                 16daf0000-16daf4000    [   16K] ---\/rwx SM=NUL  ... for thread 2\n      Stack                       16daf4000-16db7c000    [  544K] rw-\/rwx SM=PRV  thread 2",
  "exception" : {"codes":"0x0000000000000002, 0x000000016daf3f58","rawCodes":[2,6135168856],"type":"EXC_BAD_ACCESS","signal":"SIGBUS","subtype":"KERN_PROTECTION_FAILURE at 0x000000016daf3f58"},
  "termination" : {"flags":0,"code":10,"namespace":"SIGNAL","indicator":"Bus error: 10","byProc":"exc handler","byPid":19354},
  "vmregioninfo" : "0x16daf3f58 is in 0x16daf0000-0x16daf4000;  bytes after start: 16216  bytes before end: 167\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      Stack                       16da68000-16daf0000    [  544K] rw-\/rwx SM=PRV  thread 1\n--->  STACK GUARD                 16daf0000-16daf4000    [   16K] ---\/rwx SM=NUL  ... for thread 2\n      Stack                       16daf4000-16db7c000    [  544K] rw-\/rwx SM=PRV  thread 2",
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 2,
  "threads" : [{"id":6700938,"threadState":{"x":[{"value":18446744073709551612},{"value":0},{"value":4871},{"value":0},{"value":150997247},{"value":3},{"value":0},{"value":0},{"value":4871},{"value":16908290},{"value":17},{"value":0},{"value":8077116824,"symbolLocation":0,"symbol":"vm_page_size"},{"value":13883},{"value":0},{"value":0},{"value":515},{"value":8227993040},{"value":0},{"value":6135132160},{"value":2},{"value":6135132212},{"value":16908290},{"value":8077074336,"symbolLocation":224,"symbol":"_main_thread"},{"value":8077131844,"symbolLocation":0,"symbol":"_pthread_list_lock"},{"value":17},{"value":0},{"value":1664},{"value":6134518576}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6632502428},"cpsr":{"value":1073745920},"fp":{"value":6134314656},"sp":{"value":6134314560},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632236652},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":13932,"symbol":"__ulock_wait","symbolLocation":8,"imageIndex":1},{"imageOffset":38044,"symbol":"_pthread_join","symbolLocation":608,"imageIndex":2},{"imageOffset":602384,"symbol":"Jidac::verify(bool)","symbolLocation":2960,"imageIndex":0},{"imageOffset":435728,"symbol":"Jidac::add()","symbolLocation":41792,"imageIndex":0},{"imageOffset":724268,"symbol":"main","symbolLocation":444,"imageIndex":0},{"imageOffset":24800,"symbol":"start","symbolLocation":2360,"imageIndex":3}]},{"id":6701078,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":47800,"symbol":"__fread","symbolLocation":256,"imageIndex":5},{"imageOffset":82296,"symbol":"fread","symbolLocation":64,"imageIndex":5},{"imageOffset":678164,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":1580,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":73916},{"value":0},{"value":524288},{"value":9},{"value":6134601664},{"value":616562688},{"value":105553516606112},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":130},{"value":144384},{"value":6266496},{"value":64949},{"value":4294934537},{"value":225},{"value":4294934015},{"value":396},{"value":8227994568},{"value":0},{"value":8077109392,"symbolLocation":304,"symbol":"usual"},{"value":2147482624},{"value":8077109392,"symbolLocation":304,"symbol":"usual"},{"value":6134607032},{"value":6134607032},{"value":524287},{"value":0},{"value":524288},{"value":8077109416,"symbolLocation":328,"symbol":"usual"},{"value":524288}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":4096},"fp":{"value":6134600368},"sp":{"value":6134600368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}},{"triggered":true,"id":6701079,"threadState":{"x":[{"value":6135169320},{"value":8077100728,"symbolLocation":0,"symbol":"__global_locale"},{"value":4333389702,"symbolLocation":9503,"symbol":"MD5::getHash()::dec2hex"},{"value":6135173888},{"value":4333389702,"symbolLocation":9503,"symbol":"MD5::getHash()::dec2hex"},{"value":6135173888},{"value":6135173888},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":989108124556066851},{"value":989108124556066851},{"value":6135169752},{"value":4294902280},{"value":46},{"value":14757395258967641293},{"value":10},{"value":4294967287},{"value":11236567116},{"value":0},{"value":0},{"value":8077100728,"symbolLocation":0,"symbol":"__global_locale"},{"value":1},{"value":358816251},{"value":760004251},{"value":1},{"value":4333751029,"symbolLocation":0,"symbol":"tohuman2(long long)::io_buf"},{"value":47},{"value":0},{"value":4333389702,"symbolLocation":9503,"symbol":"MD5::getHash()::dec2hex"},{"value":1}],"flavor":"ARM_THREAD_STATE64","lr":{"value":14228278604378154948},"cpsr":{"value":1610616832},"fp":{"value":6135169296},"sp":{"value":6135168304},"esr":{"value":2449473607,"description":"(Data Abort) byte write Translation fault"},"pc":{"value":6631030660,"matchesCrashFrame":1},"far":{"value":6135168856}},"frames":[{"imageOffset":8068,"symbol":"__vfprintf","symbolLocation":60,"imageIndex":5},{"imageOffset":182212,"symbol":"_vsnprintf","symbolLocation":224,"imageIndex":5},{"imageOffset":96804,"symbol":"myprintf(char const*, ...)","symbolLocation":84,"imageIndex":0},{"imageOffset":280892,"symbol":"myavanzamentoby1sec(long long, long long, long long, bool)","symbolLocation":676,"imageIndex":0},{"imageOffset":678680,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":2096,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}]},{"id":6701080,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":47800,"symbol":"__fread","symbolLocation":256,"imageIndex":5},{"imageOffset":82296,"symbol":"fread","symbolLocation":64,"imageIndex":5},{"imageOffset":678164,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":1580,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":97889},{"value":0},{"value":524288},{"value":24},{"value":6135748544},{"value":15744},{"value":105553516789120},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":130},{"value":39424},{"value":6266496},{"value":64949},{"value":4294934552},{"value":20},{"value":4294934015},{"value":396},{"value":8227994568},{"value":0},{"value":8077109544,"symbolLocation":456,"symbol":"usual"},{"value":2147482624},{"value":8077109544,"symbolLocation":456,"symbol":"usual"},{"value":6135753912},{"value":6135753912},{"value":524287},{"value":0},{"value":524288},{"value":8077109568,"symbolLocation":480,"symbol":"usual"},{"value":524288}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":4096},"fp":{"value":6135747248},"sp":{"value":6135747248},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}},{"id":6701081,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":194220,"symbol":"_fseeko","symbolLocation":732,"imageIndex":5},{"imageOffset":80876,"symbol":"fseeko","symbolLocation":92,"imageIndex":5},{"imageOffset":141368,"symbol":"prendidimensionefile(char const*)","symbolLocation":40,"imageIndex":0},{"imageOffset":677536,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":952,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":2938},{"value":0},{"value":4096},{"value":105553168310192},{"value":105553168310272},{"value":32},{"value":105553168310144},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":15},{"value":0},{"value":0},{"value":0},{"value":117626},{"value":2},{"value":73},{"value":396},{"value":8227994568},{"value":0},{"value":8077110152,"symbolLocation":1064,"symbol":"usual"},{"value":0},{"value":2},{"value":2938},{"value":1},{"value":0},{"value":6136321152},{"value":760004251},{"value":6136851984},{"value":6136852240}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":1073745920},"fp":{"value":6136320576},"sp":{"value":6136320576},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}},{"id":6701082,"frames":[{"imageOffset":9376,"symbol":"__open_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":88560,"symbol":"open$NOCANCEL","symbolLocation":64,"imageIndex":1},{"imageOffset":64768,"symbol":"fopen","symbolLocation":92,"imageIndex":5},{"imageOffset":141168,"symbol":"freadopen(char const*)","symbolLocation":28,"imageIndex":0},{"imageOffset":677504,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":920,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":11},{"value":0},{"value":0},{"value":105553161393008},{"value":105553161393024},{"value":32},{"value":105553161392928},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":438},{"value":8},{"value":92358976754688},{"value":92358976754690},{"value":21504},{"value":92358976754688},{"value":2768404515},{"value":35},{"value":398},{"value":8227994296},{"value":0},{"value":0},{"value":105553161392352},{"value":105553161392352},{"value":0},{"value":6137425376},{"value":0},{"value":6137425624},{"value":760004251},{"value":6137425424},{"value":6137425680}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6632311280},"cpsr":{"value":1073745920},"fp":{"value":6136894288},"sp":{"value":6136894240},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632232096},"far":{"value":0}}},{"id":6701083,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":194220,"symbol":"_fseeko","symbolLocation":732,"imageIndex":5},{"imageOffset":80876,"symbol":"fseeko","symbolLocation":92,"imageIndex":5},{"imageOffset":141368,"symbol":"prendidimensionefile(char const*)","symbolLocation":40,"imageIndex":0},{"imageOffset":677536,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":952,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":3440},{"value":0},{"value":4096},{"value":105553516616768},{"value":105553516616832},{"value":32},{"value":105553516616736},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":15},{"value":0},{"value":0},{"value":0},{"value":3440},{"value":2},{"value":76},{"value":396},{"value":8227994568},{"value":0},{"value":8077110608,"symbolLocation":1520,"symbol":"usual"},{"value":0},{"value":2},{"value":3440},{"value":1},{"value":0},{"value":6137468032},{"value":760004251},{"value":6137998864},{"value":6137999120}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":1073745920},"fp":{"value":6137467456},"sp":{"value":6137467456},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}},{"id":6701084,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":194220,"symbol":"_fseeko","symbolLocation":732,"imageIndex":5},{"imageOffset":80876,"symbol":"fseeko","symbolLocation":92,"imageIndex":5},{"imageOffset":141368,"symbol":"prendidimensionefile(char const*)","symbolLocation":40,"imageIndex":0},{"imageOffset":677536,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":952,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":2874},{"value":0},{"value":4096},{"value":16},{"value":105553516789696},{"value":32},{"value":105553516789600},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":15},{"value":0},{"value":0},{"value":0},{"value":318266},{"value":28},{"value":4294934015},{"value":396},{"value":8227994568},{"value":0},{"value":8077110456,"symbolLocation":1368,"symbol":"usual"},{"value":0},{"value":2},{"value":2874},{"value":1},{"value":0},{"value":6138041472},{"value":760004251},{"value":6138572304},{"value":6138572560}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":1073745920},"fp":{"value":6138040896},"sp":{"value":6138040896},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}},{"id":6701085,"frames":[{"imageOffset":14368,"symbol":"__read_nocancel","symbolLocation":8,"imageIndex":1},{"imageOffset":186180,"symbol":"__sread","symbolLocation":24,"imageIndex":5},{"imageOffset":47460,"symbol":"_sread","symbolLocation":32,"imageIndex":5},{"imageOffset":47352,"symbol":"__srefill1","symbolLocation":36,"imageIndex":5},{"imageOffset":47800,"symbol":"__fread","symbolLocation":256,"imageIndex":5},{"imageOffset":82296,"symbol":"fread","symbolLocation":64,"imageIndex":5},{"imageOffset":678164,"symbol":"franz_do_hash::filehash(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, bool, long long, long long)","symbolLocation":1580,"imageIndex":0},{"imageOffset":712372,"symbol":"scansionahash(void*)","symbolLocation":272,"imageIndex":0},{"imageOffset":28724,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":2},{"imageOffset":7740,"symbol":"thread_start","symbolLocation":8,"imageIndex":2}],"threadState":{"x":[{"value":235846},{"value":0},{"value":524288},{"value":17},{"value":6138615744},{"value":12192},{"value":105553516605344},{"value":4333365881,"symbolLocation":11,"symbol":"myulltoa(unsigned long long, int)::xlat"},{"value":6631208748,"symbolLocation":0,"symbol":"__sread"},{"value":130},{"value":140288},{"value":6266496},{"value":64949},{"value":4294934545},{"value":217},{"value":4294934015},{"value":396},{"value":8227994568},{"value":0},{"value":8077109088,"symbolLocation":0,"symbol":"usual"},{"value":2147482624},{"value":8077109088,"symbolLocation":0,"symbol":"usual"},{"value":6138621112},{"value":6138621112},{"value":524287},{"value":0},{"value":524288},{"value":8077109112,"symbolLocation":24,"symbol":"usual"},{"value":524288}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6631208772},"cpsr":{"value":4096},"fp":{"value":6138614448},"sp":{"value":6138614448},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6632237088},"far":{"value":0}}}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 1212416,
    "uuid" : "23d7e721-8e5d-310e-b42b-f413028db4a7",
    "path" : "\/opt\/homebrew\/*\/zpaqfranz",
    "name" : "zpaqfranz"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 241648,
    "uuid" : "8e284c01-80f9-3be7-b660-3cca3893bb20",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 53236,
    "uuid" : "75288deb-6d30-3e42-8799-88302598394b",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 607000,
    "uuid" : "9f091f00-ff69-358f-8d89-adf6bccf8422",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 520188,
    "uuid" : "253bbb56-ff67-3189-b5c1-d651e35322cf",
    "path" : "\/usr\/lib\/system\/libsystem_c.dylib",
    "name" : "libsystem_c.dylib"
  }
],
  "sharedCache" : {
  "base" :<PHONE_NUMBER>,
  "size" :<PHONE_NUMBER>,
  "uuid" : "b015a7de-cec9-38ee-93e9-43fb3debde90"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=893.2M resident=0K(0%) swapped_out_or_unallocated=893.2M(100%)\nWritable regions: Total=1.6G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=1.6G(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nKernel Alloc Once                   32K        1 \nMALLOC                             1.6G       53 \nMALLOC guard page                   96K        6 \nSTACK GUARD                       56.1M        9 \nStack                             12.2M        9 \n__AUTH                              46K       12 \n__AUTH_CONST                        76K       39 \n__DATA                             417K       40 \n__DATA_CONST                       203K       41 \n__DATA_DIRTY                        79K       22 \n__LINKEDIT                       886.7M        2 \n__OBJC_RO                         70.8M        1 \n__OBJC_RW                         2156K        1 \n__TEXT                            6640K       43 \ndyld private memory                272K        2 \nshared memory                       80K        4 \n===========                     =======  ======= \nTOTAL                              2.6G      285 \n",
  "legacyInfo" : {
  "threadTriggered" : {

  }
},
  "logWritingSignature" : "954f84f7df65c5ac34640376fce35e235143af41",
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "64b21a7351cbb02ce3442e4e",
      "factorPackIds" : {
        "REMINDERS_GROCERY" : "64d6bf89aa6c2933834d3f9d"
      },
      "deploymentId" : 250000016
    },
    {
      "rolloutId" : "5ffde50ce2aacd000d47a95f",
      "factorPackIds" : {

      },
      "deploymentId" : 250000328
    }
  ],
  "experiments" : [
    {
      "treatmentId" : "6dd670af-0633-45e4-ae5f-122ae4df02be",
      "experimentId" : "64406ba83deb637ac8a04419",
      "deploymentId" : 900000017
    }
  ]
}
}

Sadly I do not have an M1 Mac.
Please try this workaroud: use the -noeta switch
This will "turn off" the advancement (i.e. the myavanzamentoby1sec function) which may be the culprit.
If the problem does not recur, then the error is in there, and we will investigate further
Please let me know, thanks

Thanks @fcorbelli
I added the -noeta switch to my script. It runs automated anyway in the background, so there is nobody there to see the ETA anyway. I will let you know if I see further crashes.

Might be too soon to tell, but so far, no crashes since adding -noeta

I've had your .cpp locally, so I took a look for a moment (I haven't run anything): could it be that in
char* mymigliaia(int64_t i_bytes,char* i_buffer,int i_buffersize)

This one
    char *p=&i_buffer[sizeof(i_buffer)-1]

should rather use i_buffersize?

could it be that in
char* mymigliaia(int64_t i_bytes,char* i_buffer,int i_buffersize)

This one
    char *p=&i_buffer[sizeof(i_buffer)-1]

should rather use i_buffersize?

Specifically, I believe that the cited line is equivalent to
 char *p=&i_buffer[7]

and that's improbable to be intentional.

@janko-js Nice catch. I checked that function with chatGPT and it seems to agree...

It's definitely a bug, due to a change from a vector of fixed size, for which sizeof works, to a pointer, for which it returns the size of the pointer and not of the vector

It's definitely a bug, due to a change from a vector of fixed size, for which sizeof works, to a pointer, for which it returns the size of the pointer and not of the vector

And the potential memory corruption that later can probably sometimes cause a crash (depending what's in memory before) could happen at the moment when the function processes a big enough number. That corruption doesn't have to cause immediate crash, but a delayed one.

If you look at those lines you find my correction, against sizeof(), but in another function
😄
///	snprintf(i_buffer,sizeof(i_buffer),"%.02lf %s",mybytes,myappend[i]);
	snprintf(i_buffer,i_buffersize,"%.02f %s",mybytes,myappend[i]);

Please check the attached pre-release
58_11s.zip

Still, that would not crash if the numbers to print are small. However this can totally be problematic:
inline char* migliaia3(int64_t n)
{
    static char retbuf[30];
    return mymigliaia(n,retbuf,30);
}

There are multiple functions (IDK why identical) which must be designed anew. Specifically, one should never return from the function the pointer to the buffer which semantically stops to exists during the execution of "return" -- return, by definition, returns there an invalid pointer, and different platforms could generate a code that is completely unsafe.

I wrote something here about invalid pointer, but it's actually static (I missed that detail!) so I deleted the previous post. But then the potential problem is running in multiple threads, more threads "attacking" the same static buffers, also a problem.

There is a mutex on the output, so this doesn't happen
It's a choice for performance

Something like that
lock(job.mutex);
(print something)
release(job.mutex);

If you mutex, that can still potentially cost more performance then  having local
char buff1[...], buff2[ ]
... migl( buff1, x ),   migl( buff2, y) ...

Mutex is mandatory for console output
Therefore only a single thread can call the output function migliaia
Better, the functionS migliaia
No C++ strings allowed, too slow
Yep weird, but fast

Yes I'm not talking about C++ but on passing up to N buffer pointers to local buffers to a single myg function instead of having "static" buffers and N myg functions

Different functions is the fastest overall implementation, kind of "function unrolling"
Because you have to call multiple times for a single output row with printf %s
Up to 5 in fact
You really do not want to allocate and deallocate on stack char buffers, for (worst case) millions of times
And you do not want any kind of conversions of char to strings etc
As I said it is a performance issue

Because you have to call multiple times for a single output row with printf %s Up to 5 in fact You really do not want to allocate and deallocate on stack char buffers, for (worst case) millions of times And you do not want any kind of conversions of char to strings etc

I know it differently, and I'm quite sure also in the use case there, where you use these statics, one "allocation" on the stack of a few local char[30 ] buffers in a function which is calling myprintf and a few  miglias is practically zero cost operation (most of the time introducing zero new T states spent, and neither dependent on N in buff1 or buff1, buff2, buffN there, and, of course, nor on M which would be the sum of the bytes needed) and at the same time can even be less stressful for the CPU caches (a few bytes on the stack practically always in all CPU mem caches) than access of the statics (in data segment somewhere not touched since who knows when). And I agree, I would also avoid using C++ "string" classes there.
It's all measurable, and in almost any real-life code (doing complex enough work) local "plain" variables (and char [ ] are such too) are faster than statics. It also helps avoiding functions with many parameters, but simply passing pointers to "plain" structures around instead, where such structures are totally ok to be on the stack too, also practically needing "zero" time for what you refer to as "allocation".

The situation is more complex than you think
The problem concerns the use, in a single printf, of multiple integer to string conversions (with dots)
Something like
printf("ciao %s  %s  %s  %s %s\n",migliaia(10),migliaia(100),migliaia(1000),migliaia(10000),migliaia(100000));

You REALLY do not want to "split" in multiple printf(), like
printf("ciao ");
migliaia(10);
printf(" ");
migliaia(100);
printf(" ");
migliaia(1000);
printf(" ");
migliaia(10000);
printf(" ");
migliaia(100000);
printf("\n");

To make a single printf you need (in this example) 5 ready strings. They can be C++ strings, in which case you will use c_str(), or null-terminated char* (C strings). Obviously the second case is preferable (much faster)
The problem now is to have "something" capable of converting integers to text. For C strings (char*) this is not possible, because you will have to allocate memory "somewhere" (e.g. on the heap), and then you will have to deallocate it (malloc/free => internal fragmentation), or on the stack, every time
Like (suppose a migliaia function that get, as 2nd parameter, the output char buffer)
char string1[30];
char string2[30];
char string3[30];
char string4[30];
char string5[30];
migliaia(10,string1);
migliaia(100,string2);
migliaia(1000,string3);
migliaia(10000,string4);
migliaia(100000,string5);

printf("ciao %s %s %s %s %s\n",string1,string2,string3,string4,string5);

You cannot even return an array of characters allocated on the stack, i.e. a local variable of a function, just in your deleted post
You can, of course, create functions and helper structures, creating "your" strings, similar to C++, but at that point you might as well use std::string (too slow indeed)
This is why the various solutions have already been examined, with profiling (i.e. concrete measurement of performance), arriving at today's solution.
More precisely, in reality, there were actually different functions (function unrolling) for maximum performance but it was so bad, stylistically, that I decided to refactor along the lines (introducing the bug in question, having corrected one but not the two functions of conversion)
And no, passing structures to functions slows down.
Sometimes it's not a problem, sometimes it is
The "amateur" approaches, let's say from a programmer with little experience who has read about patterns and antipatterns in books, are very far from the professional approaches of those who have been programming for thirty years, and perhaps have also programmed compilers and perhaps programmed in assembly for decades
You read "do not pass a lot of parameters to a function, this is bad and can make issues"
True
If you are programming a software with a GUI or that does almost "nothing" all the time (aka: not CPU bound)
Sometimes I'm lazy, and I don't care, to use decidedly sub-optimal systems.
Sometimes, however, I enjoy writing as it was done when programs occupied a maximum of 1000 bytes (the video memory of a Commodore 64)
You will see many apparently strange things, for less experienced programmers, such as the use of dozens and dozens of Boolean variables for switches, instead of much more elegant and compact structures (like maps, vectors or whatever you want)
The reason, again, is performance
Testing a boolean variable is orders of magnitude faster than querying a complex structure.
Sometimes also try to reduce the number of variables tested, to hope for an optimization in one CPU register (this is rarely achieved) by the compiler
And, within cycles repeated millions or billions of times [like in a compressor] the difference becomes noticeable
Then there are many more hard core approaches, i.e. specific optimizations for the single CPU, which are natural for an old assembler developer like me (e.g. the CPUID instruction is normally faster than an if(booleanvariable) and also reduces cache flush)
But I'm avoiding them, because CPUs are now among the strangest, and you can't assume that what is "smart" for processor X is also smart for processor Y, perhaps completely different
Short version: if you don't understand the "why" of a solution, maybe it has already been thought of, rethought, measured and optimized over time.
Or, even, it is simply wrong 😄

The principle used in the example you've given, let's call that principle (1):
char s1[30], s2[30], s3[30], char s4[30], s5[30];
myf(10,s1); myf(100,s2); myf(1000,s3); myf(10000,s4); myf(100000,s5);
printf("ciao %s %s %s %s %s\n",s1,s2,s3,s4,s5);

is indeed that what I've suggested, in most real-life uses, to be faster, and in the rest of the cases, at least not slower than your "static char []" way (let's call that (2)). As I've mentioned: what you call an "allocation" in a function which already has its own stack frame doesn't cost any new cycles, as long as you still use char [ ] (and not C++ string classes) and it can be more cache friendly than your preferred "static" solution.
The function containing that printf typically already has to have its own stack frame and the instructions executed for that are identical, with or without the existence of the space on the stack reserved for these s1..s5.  Additionally, in the specific example of yours, the execution times of myf and printf are already orders of magnitude higher than that stack frame maintenance, making the difference, which you say exists, probably immeasurable.
If you have actually observed the difference between (1) against (2) in the actual use, I'm curious to learn about some specific location in zpaqfranz where that can be seen in measurements. I can imagine a special example of a function which in the (2) case wouldn't need its stack frame, if the function code created due to (1) results in the need for the stack frame to be introduced by a compiler. It would be interesting to me to see an example where that actually happens and really changes the execution time (as in: "I measure ... with 1 and ... with 2). That would be a new insight for me.

The principle used in the example you've given, let's call that principle (1):
char s1[30], s2[30], s3[30], char s4[30], s5[30];
myf(10,s1); myf(100,s2); myf(1000,s3); myf(10000,s4); myf(100000,s5);
printf("ciao %s %s %s %s %s\n",s1,s2,s3,s4,s5);

is indeed that what I've suggested, in most real-life uses, to be faster, and in the rest of the cases, at least not slower than your "static char []" way (let's call that (2)).

The syntactic complexity becomes enormous.
That is, you have to write code upon code upon code, to get the same result in terms of performance
So it is a worse choice
If you are curious to look for the "archaic" versions of zpaqfranz you will see different solutions for this problem.
Frankly, I have not kept track of it, it is inside the sources
The question to be answered is: is the currently implemented solution concise (syntactically) and fast (in execution)?
If the answer is yes, then it is the best tradeoff (under the circumstances)

To summarize, I'm saying for this, what I call (1):
// (1)
// works always, uses stack
char s1[30], s2[30], s3[30], s4[30], s5[30];
myf(10,s1); myf(100,s2); myf(1000,s3); myf(10000,s4); myf(100000,s5);
printf("ciao %s %s %s %s %s\n",s1,s2,s3,s4,s5);

I don't expect to be possible to measure in practical use cases to be slower (and I explained the technical reasons for that) than this:
// (2)
// needs functions with different names
inline char* myf1(int64 x)
{
    static char s[ 30 ]; // uses data segment
    return myf( x, s );
}
inline char* myf2(int64 x)
{
    static char s[ 30 ];
    return myf( x, s );
}
inline char* myf3(int64 x)
{
    static char s[ 30 ];
    return myf( x, s );
}
inline char* myf4(int64 x)
{
    static char s[ 30 ];
    return myf( x, s );
}
inline char* myf5(int64 x)
{
    static char s[ 30 ];
    return myf( x, s );
}
lock( ); // needs locks <-- critical before use of myfN because they depend on "static" vars
printf("ciao %s %s %s %s %s\n",
    myf1(10),myf2(100),myf3(1000),myf4(10000),myf5(100000));
unlock( );

and also that (1) has the advantages of not depending on the locks used in the correct places to be able to trust the results of the output as soon as the code is called from more threads. You call the approach (1) "code upon code upon code", and I don't see it that way.
I understood you that you like the trade-off you use, and I agree that you can do what you like in your own code.
I personally consider (2) a kind of code which is has bigger potential to result in the output which can contain something that doesn't reflect the information that was supposed to be printed (due to the mentioned locking issues) but I definitely know that after informing you about that I really can't expect from you to do anything about it. Thanks.

I've also forgotten to make it fully clear: if you ever happen to have the calls to the functions containing uses of statics like this, and it happens that they are executed in parallel from different threads (i.e. the correct locks() didn't protect from that) that remains a source of potential crashes, even after the sizeof() bug is corrected. That is the main reason I've pointed to that, I really have no interest to discuss the esthetic preferences of the sources here, just what is actually executed as a consequence of something written.

Context is key
During important phases (i.e., multithread compression), you cannot run the risk of having any race condition between threads, full stop.
The output must be serialized, and here is the mutex
This solves any possible issues at the root
On support functions (e.g., multithreaded folder scanning), on the other hand, the issue is much more relaxed
You can get inexact results (partially overwritten), not crashes
But there is not the slightest importance in the correctness of the data shown, they are advances info, nobody really cares
You can even find on the developer forum my thread on this very situation
Short version: in critical section you must serialize the output => you must use a mutex or whatever => no possible crashes, no possible overwrite => already done
Everywhere else... who care? 😄
PS as you have seen, or maybe not, there is NOT printf() in zpaqfranz, but myprintf()
Because I can easilly put a mutex right here, in myprintf(), if I really want to be sure
myprint(whatever)
{
lock( ); // needs locks <-- critical before use of myfN because they depend on "static"
printf(whatever)
unlock( );
}

myprintf("ciao");
myprintf("cucu");

But, in fact, there is something like that (with explicit pthread mutex)
pthread_mutex_lock(&g_mylock);
				if ((!flagsilent) && (!flagnoconsole))
				{
					setupConsole();
					printf("\033[%d;0H",(int)i_tnumber+1);
					restoreConsole();
				}
				myprintf("Thread %02d %03d s %12s: speed (%11s/s)",i_tnumber,trascorso,i_runningalgo.c_str(),tohuman3((int64_t)o_speed));
				pthread_mutex_unlock(&g_mylock);

I wrote my previous message after seeing:

You can get inexact results (partially overwritten), not crashes

Reading that lead me to believe that you aren't familiar with write reordering issues, as I can't imagine that it's possible to claim that without the  locks. And with the locks I haven't expect partial overwrites.
I'm also not familiar with Motorola 68K architecture which was ever able exhibit the Arm-like conditions for reordering, so I don't know how that's relevant.
If you already lock in all needed places, then I admit that there will be no mysterious crashes that are the consequence of your preferential use of static variables in multithreaded code.

This conversation was surely an interesting read and went way over my head. But thank you @janko-js for your insights and especially thank you @fcorbelli for fixing the crash. 🙏


When I use this theme on Shopify, no payment icon appears, although I checked the payment icon

Hi,
The icons are automatically shown by Shopify according to the enabled payment methods on your Shopify store.
https://help.shopify.com/en/manual/payments/shopify-payments/setting-up-shopify-payments
If you are just starting out and want to test the payment you may enable the Bogus gateway like we do on our demos for example.
https://help.shopify.com/en/manual/payments/shopify-payments/testing-shopify-payments


making xml_et.node_type() resilient to missing type information

Codecov Report

Merging #159 (ba3cf29) into master (b739754) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #159   +/-   ##
=======================================
  Coverage   42.49%   42.50%
=======================================
  Files          50       50
  Lines       23429    23430    +1
=======================================
+ Hits         9957     9958    +1
  Misses      13472    13472

Impacted Files
Coverage Δ

resqpy/olio/xml_et.py
59.68% <100.00%> (+0.08%)
:arrow_up:

Continue to review full report at Codecov.

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


param-based args to bound C++

Many of the dripline-cpp classes have constructors which take a config. There are two issues which should both be addressed:

there should generally be support for providing param-typed data in a config file to be passed as a kwarg (we have casting between python dicts and param_node in scarab already). This would allow any future config terms to automatically be available
known parameters should be explicitly listed as available kwargs which are reflected in the function's help etc.)

This is resolved in v4.1.0


🌱 Bump CAPI to v1.7.0-beta.1

as title says

/test all

@Sunnatillo can we take it out of draft ?

/test-centos-e2e-integration-main
/test-ubuntu-integration-main


withSASS: custom webpack giving window not defined error.

I have my next.config.js as below.
\\next.config.js
const withCSS = require('@zeit/next-css');
const withSASS = require('@zeit/next-sass');
const withPlugins = require('next-compose-plugins');
const optimizedImages = require('next-optimized-images');
const path = require("path");

module.exports = withPlugins([
  [withCSS, {
    webpack: function (config) {
      config.module.rules.push({
        test: /\.(eot|woff|woff2|ttf|svg|png|jpg|gif)$/,
        use: {
          loader: 'url-loader',
          options: {
            limit: 100000,
            name: '[name].[ext]'
          }
        }
      })
      return config
    }
  }],
  [withSASS, {
    webpack: (config) => {
      config.module.rules[3].use = [
        { loader: "style-loader" },
        { loader: "css-loader" },
        { loader: "sass-loader" },
        {
          loader: "sass-resources-loader",
          options: { resources: require(path.join(__dirname, "./cssUtil.js")) }
        }];
      return config;
    }
  }],
  [optimizedImages, {
    optimizeImagesInDev: true
  }]
], (config) => {
  console.log(config);
});

Footer.js
...
import "Footer.scss";
...

Footer.scss
.footer {
  ...
}

Error
 ReferenceError: window is not defined
    at /Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:2240:2
    at /Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:2229:46
    at module.exports../node_modules/style-loader/lib/addStyles.js.module.exports (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:2297:88)
    at Object../src/common/components/Footer/Footer.scss (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:3194:143)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Module../src/common/components/Footer/Footer.js (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:3060:71)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Module../src/common/components/Footer/index.js (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:3596:65)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Module../src/containers/Layout/Layout.js (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:6337:83)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Module../src/containers/Layout/index.js (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:6449:65)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Module../pages/_app.js (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:2747:81)
    at __webpack_require__ (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:23:31)
    at Object.0 (/Users/vdoma001/IdeaProjects/7-Eleven-React/.next/server/static/development/pages/_app.js:8381:18)

Hi, thanks for creating an issue. We currently recommend using https://nextjs.org/docs/basic-features/built-in-css-support as the plugins have been deprecated in favor of the built-in support.


Allow unauthenticated APT Mirror

Openstack infra provide APT mirrors, but they are not signed. In order
to make use of these for gating it is necessary to disable security
hardening rule V-38462.
Connects rcbops/u-suk-dev#300
(cherry picked from commit 72a51b435cefeacb1e851209d9ed4b66dd931475)

recheck_ceph

recheck_ceph

:-1: We don't have security hardening in kilo? Is this necessary?

Excellent point @major.


Switch to cgra_pnr

Some minor changes to makefile and scripts/repo_manager.py to install cgra_pnr in the CGRAFlow. Currently it passed all the tests.
Not sure if I should remove old SMT PnR stuff...
Please let me know if you have any questions.

Keyi, this is excellent work!  Especially considering that you are on vacation :)

Not sure if I should remove old SMT PnR stuff...
Looks like you did remove it, yes?  That's fine; the purpose of CGRAFlow is to prove that we can get from Halide to correct image-out, not to test everyone's routers...

After this / soon / eventually we need to figure out how to add cascade and halide...
Meanwhile I approve this merge.

I want to approve the changes but...
even though I refresh, the pull request page keeps saying checks haven't completed yet...must be a bug b/c when I look at the builds they all say "passing"...guess I will wait and see if it resolves itself :(

Okay even though it still says "checks haven't completed" I can see that they have passed so I'm going to go ahead approve this merge (again).

What is the status of this pull, why was it never completed...?

I think we were waiting on the checks to complete, which it looks like they did.


support flexible labels in _get_time_series

_get_time_series fetches a forecast that is hardcoded to a specific label (renewables = rating, loads = maxactivepower).
We should allow the user to specify which forecast label they want.

Never-mind. This should be hardcoded with the accessor functions. We support the formulations that are predicated on accessing the fields in this implementation. If a user wants to extend that's fine, but they will need to ensure that they are accessing the fields that they want to...


Provide an NPM package

Is the project still in progress? Are folks just installing this from github?
$ npm install react-native-twitterkit
npm ERR! Darwin 16.6.0
npm ERR! argv<EMAIL_ADDRESS>"/usr/local/bin/npm" "install" "react-native-twitterkit"
npm ERR! node v6.10.2
npm ERR! npm  v4.2.0
npm ERR! code E404

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/react-native-twitterkit
npm ERR! 404
npm ERR! 404  'react-native-twitterkit' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.```

Currently, we use it using a github dependency, yes.

I think this should be closed since you already have a npm package

@iamhush hmm, yes someone published a npm package from a fork of this repository, but that wasn't us.
Would be nice if this person gets in touch so we can organize the support better.

@ognen But then why do you have it on the readme ?

@iamkhush ... seems a leftover from a project template. Fixed it.


unable to append numeric and unicode string records

I'm new to Python and zarr and think this is a question and not an issue.
When appending numeric values to zarr everything works fine. See few lines below
mydtype1 = np.dtype([("a", ">i4"), ("b", ">i8"), ('c', "i8")])
zarr1 = zarr.open_array(os.path.join('temp', 'test_zarr'), mode='w', shape=(2, 3), chunks=(100, 3), dtype=mydtype1, fill_value=0)

zarr1.append([(1, 2222, 3333)])

However, when I try to append numeric values and a unicode string (encoded), Python show the error message.

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in range(128)

This is the source code:
mydtype1 = np.dtype([("a", ">i4"), ("b", ">i8"), ('c', bytes)])
zarr1 = zarr.open_array(os.path.join('temp', 'test_zarr'), mode='w', shape=(2, 3), chunks=(100, 3), dtype=mydtype1, fill_value=0)

zarr1.append([(1, 2222, bytes('asdfà', encoding='utf8'))])

I already spent many hours and I have no idea what I'm doing wrong. Changing the third dtype to object, 'U10', str has no effect on the error message.
I'm using the version: 2.1.5.dev40
Thanks in advance.

Hi Joe,
Here's one option...
In [1]: import zarr
In [2]: zarr.__version__
Out[2]: '2.1.4'
In [4]: import numpy as np
In [5]: mydtype1 = np.dtype([("a", ">i4"), ("b", ">i8"), ('c', 'U10')])
In [7]: zarr1 = zarr.open_array('test.zarr', mode='w', shape=0, chunks=100, dtype=mydtype1, fill_value=0)
In [10]: zarr1.append(np.array([(1, 2222, 'asdfà')], dtype=mydtype1))
Out[10]: (1,)
In [12]: zarr1[:]
Out[12]:
array([(1, 2222, 'asdfà')],
      dtype=[('a', '>i4'), ('b', '>i8'), ('c', '<U10')])

I've made this is a one-dimensional array with a structured dtype because I'm guessing that's what you want, i.e., something a bit like a table. So shape and chunks only need one dimension, because the fields of a structured dtype don't count as columns, they are all part of the value. (You can do multi-dimensional arrays with structured dtype if you really need them, but I'm guessing that's not the case here.)
Alternatively, using a string rather than unicode dtype for the third field...
In [13]: mydtype2 = np.dtype([("a", ">i4"), ("b", ">i8"), ('c', 'S10')])
In [14]: zarr2 = zarr.open_array('test2.zarr', mode='w', shape=0, chunks=100, dtype=mydtype2, fill_value=0)
In [15]: zarr2.append(np.array([(1, 2222, 'asdfà'.encode('utf-8'))], dtype=mydtype2))
Out[15]: (1,)
In [17]: zarr2[:]
Out[17]:
array([(1, 2222, b'asdf\xc3\xa0')],
      dtype=[('a', '>i4'), ('b', '>i8'), ('c', 'S10')])

Btw if you are storing columns of a table then might be worth considering to store each column as a separate dataset, i.e.:
In [19]: zarr3 = zarr.open_group('test3.zarr', mode='w')
In [20]: a = zarr3.zeros('a', shape=0, chunks=100, dtype='i4')
In [21]: b = zarr3.zeros('b', shape=0, chunks=100, dtype='i8')
In [22]: c = zarr3.zeros('c', shape=0, chunks=100, dtype='U10')
In [23]: a.append([1])
Out[23]: (1,)
In [24]: b.append([2222])
Out[24]: (1,)
In [25]: c.append(['asdfà'])
Out[25]: (1,)

...requires each column to be appended separately, but not bad if you append in decent-size blocks, and compression may be better. Also generally more efficient to query data organized by column like this, especially if you have many columns but only query a few at a time.
Btw if you are after table-like functionality then bcolz is similar to zarr but may be better suited.
Hth.

Hi Alistair
Thanks for your fast answer and many thanks for building such a great tool.   :-)
I think your third option would fit best for me because I'd like to use zarr to store some training/validation data to learn Tensorflow and/or Mxnet. Such as numpy array's, etc...
Thanks
Joe

No problem, glad it's useful!
On Wed, 15 Mar 2017 at 19:40, JoeSchnorcher<EMAIL_ADDRESS>wrote:

Closed #142 https://github.com/alimanfoo/zarr/issues/142.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/alimanfoo/zarr/issues/142#event-1001555581, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAq8Qmpb2QSzbqjDaPtnJLiB8OJY8GR7ks5rmD7EgaJpZM4MafTg
.

--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Email<EMAIL_ADDRESS>Web: http://purl.org/net/aliman
Twitter: https://twitter.com/alimanfoo
Tel: +44 (0)1865 287721


Get rid of git dependency

In fresh docker containers, git is often not available.
Perhaps it is possible to use the GitHub API instead?

Fixed in https://github.com/libsdl-org/setup-sdl/commit/0a1cbd654d88c5db05778102fa5996afb79ad637


Rework URL Mapping, add mapFn to routing

Sometimes you have logic around signal name and passed args in route definition.
We return Catberry map function, but specified for args/signals.
Example:
{
  expression: '/news/:filter,
  signal: 'ActiveNewsPage',
  map: function ({ signal, args }) {
     if (args.filter === 'Archive') {
        signal = 'ArchiveNewsPage';
     }

     return { signal, args };
  }
}

Looks good
:+1:


Auto-rebase does not work when auto-merge enabled

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
npm, Bundler
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
We expected the Dependency bot to still automatically rebase when there are merge conflicts after the auto-merge workflow is enabled.
However, the current behavior is that the Dependency bot stops automatically rebasing when there are merge conflicts.
And we need to manually type comments in the PR @dependabot rebase to ask the Dependency bot to rebase.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
version: 2
updates:
  - directory: /infrastructure
    package-ecosystem: npm
    schedule:
      interval: weekly
      day: wednesday
      time: "10:00"
      timezone: Australia/Melbourne
    open-pull-requests-limit: 50
    allow:
      - dependency-type: all
    commit-message:
      prefix: Dependabot

I've also noticed this. Sometimes it will rebase, but sometimes it will not. I think there might be a race condition with the checks when more than one dependency gets merged simultaneously.


pdal: 2.6.2 -> 2.6.3

Description of changes
Patch version update of PDAL.
List of changes: https://github.com/PDAL/PDAL/releases/tag/2.6.3

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 286713 run on x86_64-linux 1

1 package failed to build:

cloudcompare

5 packages built:

entwine
grass
pdal
qgis
qgis-ltr

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/week-in-geospatial-team/37035/7

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/week-in-geospatial-team/37035/8


Record audio in foreground

Feature: - Record audio in foreground
Expected Behaviour: - Record audio when the user clicks the in a foreground state, then save it to the local store in the app.
POINTS-25

Hello @shagun25! I would like to work on this issue.

@hiashutoshsingh since I'm new to flutter this issue is time consuming for me and exams are coming too. If you wish, you may assign to someone else.

@hiashutoshsingh since I'm new to flutter this issue is time consuming for me and exams are coming too. If you wish, you may assign to someone else.

Thanks for letting us know.

Can I work on that issue? I am also a GSSOC21 participant....Please assign me here @shagun25 @hiashutoshsingh

Can I work on that issue? I am also a GSSOC21 participant....Please assign me here @shagun25 @hiashutoshsingh

Hey, you have many issues to resolve as I see, I just wanted to give chance to other participants.
If this is not picked in few days I will assign it to you.

Can I work on that issue? I am also a GSSOC21 participant....Please assign me here @shagun25 @hiashutoshsingh

Hey, you have many issues to resolve as I see, I just wanted to give chance to other participants.
If this is not picked in few days I will assign it to you.

sure

Hey @shagun25 , Can you assign this issue to me?
I am new to flutter and firebase so will be great help if you could guide me a little.
This will be my very first issue, and I really want to do this.

Thanks a lot for assign me @hiashutoshsingh


Optimize

https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas

[ ] avoid floating point coordinates
[ ] multiple layer (indicator, values)
[ ] turn off transparency

TimeChart was implemented in #317


Empty shopping cart when using the browsers back button

Describe the bug
When you are on the (hpp) redirect page and presses on the browsers back button the shopping cart is emptied. When you use the link 'go back to merchant website' the shopping bag is still available
To Reproduce
Steps to reproduce the behavior:

Add some items to the basket
Select a redirect payment method
Place order and get redirected to the Adyen hpp
Press the browsers back button.

Expected behavior
Shopping bag stays available

Hi @wannevancamp ,
Thank you for opening this issue.
This is unfortunately a behaviour that is expected. As soon as the customer places the order and being redirected to the redirect page, shopware will create an order and therefore clear the cart.
The difference between the "go back to merchant website" button and the browser back button is that the first one redirects the customer back to a returnUrl that we provided and if that url is hit then it can cancel the order and reopen the cart with the same items as before while the browser back button doesn't provide any extra info so it would be the same if the customer just typed in the webshop url by hand.
With this approach we make sure that the customer cannot change the cart while paying and that the order will be created even if the customer is not redirected back to the success page at the end due to any error like network or issuer error.
I am happy to hear your thoughts about it, also do you maybe know what percentage of your customers face this issue? Do you get a lot of complains for this? Is there any other way (idea) of solving this issue for example with a button that says "cancel my previous order" whenever the customer redirects back and the payment is not done yet?
Best,
Attila
Adyen

Hi @wannevancamp ,
I will close this issue for now but I am still happy to hear your thoughts about it, also do you maybe know what percentage of your customers face this issue? Do you get a lot of complains for this? Is there any other way (idea) of solving this issue for example with a button that says "cancel my previous order" whenever the customer redirects back and the payment is not done yet?
Best,
Attila
Adyen


Missing window icon

Hi there,
On my Openbox system the brackets icon is missing in the window switching list.
See this:

Anything we can do about it?

The same is happening to me as of July 22, 2015. It happens both in Openbox and Xfce. The icon shows up in Applications -> Development, but not in the taskbar or when hitting Alt+Tab.

I can confirm this bug still exists in Brackets 1.5 (build 1.5.0-16538). While using Xfce 4.10 application icon for brackets present in Application menu, but not in window switcher (alt-tab) nor in window buttons panel applet.

I'm using xubuntu 15.04 today 04-02-2016 and still having this issue.

I have the same issue on Debian Jessie 8.3. I use Openbox and Brackets' version is Release 1.6 experimental build 1.6.0-16680 (release 3df0ac6fa).
Here is a screenshot. Notice that the icon (second from left) is missing on both taskbar and Alt-Tab menu. The first icon from left is the Openbox launcher icon and is using brackets.desktop entry.

I'm using Xubuntu 16.04, Brackets 1.8, and still having this issue.

I'm still having the issue :(

debian stretch
icons not shown on alt+tab menu for next applications

gitkraken 3.2.2
terminology 1.1.1
pinta 1.6


[BUG] Panic when following getting started tutorial

Observed behavior
Panic from inside the library.
Expected Behavior
No panic.
Steps to reproduce
This code panics:
package main

import (
	"context"
	"fmt"
	flagd "github.com/open-feature/go-sdk-contrib/providers/flagd/pkg"
	"github.com/open-feature/go-sdk/openfeature"
)

func main() {
	provider := flagd.NewProvider(flagd.WithHost("localhost"), flagd.WithPort(8013))
        // Super duper asynchronous provider initialization magic is starting to happen.

	err := openfeature.SetProvider(provider)
        // We start using the provider variable, but the super duper magic is still happening and the provider is not ready for usage yet!!!
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	client := openfeature.NewClient("app")

	ctx := context.Background()
	evalCtx := openfeature.EvaluationContext{}
        // Is the super duper magic over yet? Of course not. Panic.
	v2Enabled, err := client.BooleanValue(ctx, "v2_enabled", true, evalCtx) // This line of code panics.
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	if v2Enabled {
		fmt.Println("v2 is enabled")
	}
}

This code does not. The only difference is the added time.Sleep.
package main

import (
	"context"
	"fmt"
	flagd "github.com/open-feature/go-sdk-contrib/providers/flagd/pkg"
	"github.com/open-feature/go-sdk/openfeature"
)

func main() {
	provider := flagd.NewProvider(flagd.WithHost("localhost"), flagd.WithPort(8013))
        // Super duper asynchronous provider initialization magic is starting to happen.

       time.Sleep(time.Second*3)
       // Actually wait for the super duper asynchronous initialization to finish, as if it was actually synchronous like it's supposed to be.

	err := openfeature.SetProvider(provider)
        // We start using the provider variable, and the super duper magic is actually over and nothing bad is going to happen.
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	client := openfeature.NewClient("app")

	ctx := context.Background()
	evalCtx := openfeature.EvaluationContext{}
        // Is the super duper magic over yet? Of course! We used time.Sleep to circumvent the library's buggy behaviour.
	v2Enabled, err := client.BooleanValue(ctx, "v2_enabled", true, evalCtx) // This line of code does not panic.
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	if v2Enabled {
		fmt.Println("v2 is enabled") // Output: "v2 is enabled"
	}
}

The issue is github.com/open-feature/go-sdk@v1.8.0/pkg/openfeature/api.go:174.
For some reason, library/provider initialization is asynchronous, meaning one can use the library/provider without any guarantee that it is ready for usage, which goes against all common sense. The fix is to not do async initializaiton. I will link the pull request shortly.

Hi @i-fix-retarded-bugs . I'm sorry for the bad experience and thanks for the detailed report!
There's a couple things happening here:

Firstly, our doc is not helpful in this case. Some providers are ready immediately (those that use local rulesets, for example). Others require some initialization. In the second case, we'd hope users use the READY event handlers to await the provider's readiness before evaluating flags. However, our getting started doc misses that, and our README also doesn't mention it early enough. We also could add a new method that behaves like the one in your PR, which doesn't run async. However, we can't remove this old one since people expect it to be async. Other OpenFeature SDKs have this solution (one sync one async function).

Even if you use a provider before it's ready, it shouldn't panic - instead the default flag value you pass should be returned. There could be a bug here with either the flagd provider, OR the SDK itself. We'll look into that.

We will investigate and correct both these things if we confirm the issue.
Lastly, though I appreciate the detailed report, and though I understand your frustration, I believe your username to be in violation of the CNCF code of conduct since it contains a term many consider a slur. Your username shows up in issues, release notes, PRs, etc, and we can't let it become part of the record. We request you change your username and remove it from any commits etc. Otherwise we will re-open a similar issue in this one's place, close this one, and block this user.

Closing. See https://github.com/open-feature/go-sdk/issues/238#issuecomment-1854409704 and linked issues.


How to use

Was looking in the source code but couldn't find a way to use it. Can you update the readme file please and include a basic send message?

The readme includes a basic example of plaintext and rich text in a Laravel notification: https://github.com/nwilging/laravel-discord-bot#notification-channel-usage
The readme of this package doesn't cover implementing laravel notifications as a whole as that's outside the scope of the package - it assumes you already know how to use laravel notifications in abstract. https://laravel.com/docs/9.x/notifications#sending-notifications


Update README.md

Resolves #ISSUE
What is being addressed
Describe the current behavior you are modifying. Please also remember to update any impacted documentation.
How is this addressed

Describe the changes made, and if appropriate, why they are addressed this way
Note any pending work (with links to the issues that will address them)
Update documentation

Has the CIS document been consulted / updated?

Are you adding new resources, or modifying existing ones?
Have settings been set in line with the CIS recommendations?

/test-all

:robot: pr-bot :robot:
:runner: Running tests: https://github.com/Griff-Labs/FlowEHR/actions/runs/4677413266 (with refid e233aaf0)
(in response to this comment from @jjgriff93)


General Spelling And Grammar Fixes In The App

I went through the app itself and did my best to fix all of the general spelling and grammar mistakes I was able to spot. I also added a few extra blank lines here and there to make some of the text easier to read

Thanks, merging now. :)


[Bug] DFPatternRewriteComposer.AddRewrite with additional args raises compile error

Hi folks,
I'm trying to use DFPatternRewriteComposer defined in src/relay/transforms/simplify_expr.h to compose rewrite patterns.
Suppose some of my rewrite patterns get arguments in constructor like this,
class SimplifyXXX : public DFPatternRewrite {
  public:
    SimplifyXXX(size_t batch_size_): batch_size(batch_size_) {
      ...
    }
  ...
  private:
    size_t batch_size;
    ...
}

and I tried to add this pattern in composer like this,
size_t batch_size = 1;
DFPatternRewriteComposer composer;
composer.AddRewrite<SimplifyXXX, size_t>(batch_size);

then it results in compile error as follows.
[build] /root/tvm/src/relay/transforms/simplify_expr.h:72:55: error: invalid conversion from 'long unsigned int*' to 'long unsigned int' [-fpermissive]
[build]    72 |     rewrites_.push_back(std::make_shared<T, Args...>(&args...));
[build]       |                                                       ^~~~
[build]       |                                                       |
[build]       |                                                       long unsigned int*

So I tried to change the code in src/relay/transforms/simplify_expr.h:72 like below and there was no error. (Note that & was moved from args to Args)
rewrites_.push_back(std::make_shared<T, Args&...>(args...));

I'm quite new to tvm and modern C++, so I'm not sure whether my change is correct. Could you give any opinions about this?
Thanks!

cc @mbrookhart
This is better asked on discuss forum https://discuss.tvm.apache.org/

@masahi Ah sorry I didn't know that. I'll try to post it on there. Thanks!


[benchmark] Yield when time slice expires

It pays off of to be a nice process and yield the processor at regular intervals, to prevent having measured samples corrupted by preemptive multitasking.
When the scheduled time slice (10ms on Mac OS) is probably about to expire during the next measurement, we voluntarily yield  and resume the measurement within a fresh scheduler quantum.
This cooperative approach to multitasking improves the sample quality and robustness of the measurement process.

Please review @eeckstein (@graydon ?) 🙏

Clever! Looks good to me.

I'm unsure if I should hide this behind option or possibly make the schedulerQuantum into a configurable argument, so that we might better test the effect of this on sample quality. It doesn't do anything noticeable on a calm machine, but the point is to make the measurement more resilient to noise on a contended machine, as I'd ultimately like to make benchmarking parallel. I did remeasure the complete dataset from my report, but a lot has changed in the meantime and most of individual benchmarks are not directly comparable anymore.

To illustrate the effect of this change on a contended machine, this is a example before and after:

@swift-ci smoke benchmark

@swift-ci smoke test

Build comment file:
Build failed before running benchmark.

Build comment file:
Build failed before running benchmark.

@shahmishal Any idea why are these builds failing?

This might be an issue on the master branch, not related to your changes.
<unknown>:0: error: unable to execute command: Segmentation fault: 11
01:56:25.197 <unknown>:0: error: compile command failed due to signal 11 (use -v to see invocation)
01:56:25.946 [932/1590] Generating /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftmodule
01:56:25.946 FAILED: lib/swift/macosx/x86_64/Swift.swiftmodule lib/swift/macosx/x86_64/Swift.swiftdoc lib/swift/macosx/x86_64/Swift.swiftinterface
01:56:25.946 cd /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/stdlib/public/core && /Applications/CMake.app/Contents/bin/cmake -E remove -f /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftmodule && /Applications/CMake.app/Contents/bin/cmake -E remove -f /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftdoc && /Applications/CMake.app/Contents/bin/cmake -E remove -f /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftinterface && /usr/bin/python /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/swift/utils/line-directive @/Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/stdlib/public/core/aG1Cy.txt -- /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./bin/swiftc -emit-module -o /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftmodule -experimental-emit-interface -sdk /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -target x86_64-apple-macosx10.9 -resource-dir /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift -F /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/../../../Developer/Library/Frameworks -O -I /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64 -module-cache-path /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./module-cache -no-link-objc-runtime -Xfrontend -enable-resilience -nostdimport -parse-stdlib -module-name Swift -Xfrontend -group-info-path -Xfrontend /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/swift/stdlib/public/core/GroupInfo.json -swift-version 5 -warn-swift3-objc-inference-complete -Xfrontend -verify-syntax-tree -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xfrontend -enable-sil-ownership -Xcc -DswiftCore_EXPORTS -module-link-name swiftCore -force-single-frontend-invocation -Xcc -D__SWIFT_CURRENT_DYLIB=swiftCore -parse-as-library @/Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/stdlib/public/core/aG1Cy.txt
01:56:25.946 Stack dump:
01:56:25.946 0.	Program arguments: /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/bin/swift -frontend -emit-module -filelist /var/folders/_8/79jmzf2142z2xydc_01btlx00000gn/T/sources-a2ba25 -supplementary-output-file-map /var/folders/_8/79jmzf2142z2xydc_01btlx00000gn/T/supplementaryOutputs-2a8957 -disable-objc-attr-requires-foundation-module -target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -I /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64 -F /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/../../../Developer/Library/Frameworks -warn-swift3-objc-inference-complete -module-cache-path /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./module-cache -module-link-name swiftCore -nostdimport -parse-stdlib -resource-dir /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift -swift-version 5 -O -enable-resilience -group-info-path /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/swift/stdlib/public/core/GroupInfo.json -verify-syntax-tree -enable-sil-ownership -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xcc -DswiftCore_EXPORTS -Xcc -D__SWIFT_CURRENT_DYLIB=swiftCore -parse-as-library -module-name Swift -o /Users/buildnode/jenkins/workspace/swift-PR-osx-perf/Ninja-Release/swift-macosx-x86_64/./lib/swift/macosx/x86_64/Swift.swiftmodule
01:56:25.946 1.	Contents of /var/folders/_8/79jmzf2142z2xydc_01btlx00000gn/T/sources-a2ba25:

:-) I figured that much… I just thought there is some kind of a process for reverting a commit that brakes the build that would restore master to working order.…  (in less than 6 hours since this started)

@swift-ci benchmark

Build comment file:
No performance and code size changes

How to read the data
The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB