Manual Installation Error (MacOs)

I am on Monterey 12.7 with an AMD processor via opencore. I have downloaded Python 3.12 and run the pip3 install command from the repository folder. Python returned these errors.  I've tried the compiled .app version also. When I try to demux a wave file the application shuts down itself with no errors. What should I do?
Thank you.

ultimatevocalremovergui-master % pip3 install -r requirements.txt

Ignoring SoundFile: markers 'sys_platform != "darwin"' don't match your environment
Collecting altgraph==0.17.3 (from -r requirements.txt (line 1))
Downloading altgraph-0.17.3-py2.py3-none-any.whl (21 kB)
Collecting audioread==3.0.0 (from -r requirements.txt (line 2))
Downloading audioread-3.0.0.tar.gz (377 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 377.0/377.0 kB 928.4 kB/s eta 0:00:00
Installing build dependencies ... done
Getting requirements to build wheel ... error
error: subprocess-exited-with-error
× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> [20 lines of output]
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in
main()
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 118, in get_requires_for_build_wheel
return hook(config_settings)
^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/8z/m370scds3p13g7gp3ft1hkxc0000gn/T/pip-build-env-l7635x5f/overlay/lib/python3.12/site-packages/setuptools/build_meta.py", line 355, in get_requires_for_build_wheel
return self._get_build_requires(config_settings, requirements=['wheel'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/8z/m370scds3p13g7gp3ft1hkxc0000gn/T/pip-build-env-l7635x5f/overlay/lib/python3.12/site-packages/setuptools/build_meta.py", line 325, in _get_build_requires
self.run_setup()
File "/private/var/folders/8z/m370scds3p13g7gp3ft1hkxc0000gn/T/pip-build-env-l7635x5f/overlay/lib/python3.12/site-packages/setuptools/build_meta.py", line 507, in run_setup
super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script)
File "/private/var/folders/8z/m370scds3p13g7gp3ft1hkxc0000gn/T/pip-build-env-l7635x5f/overlay/lib/python3.12/site-packages/setuptools/build_meta.py", line 341, in run_setup
exec(code, locals())
File "", line 17, in
ModuleNotFoundError: No module named 'imp'
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.

try the latest dmg, it fix mdx and demucs for mps

try the latest dmg, it fix mdx and demucs for mps

May I ask what do you mean by dmg? DMG of vocalremover app itself or python? Or vocalremover repository?


Calibration called several times in TFragment.cxx

Hi guys,
The public function GetEnergy() in the TFragment class is called in GetTime() and GetTZero() respectively. So the same charge calibration procedure is potentially called several times, I don't see any benefit. Any explanation?

I don’t think it actually is, calling GetTime() calls TChannel::GetTZero not TFragment::GetTZero.
The Fragment calls make the GetEnergy call. but the TChannel::GetTZero(double) then calls TChannel::CalibrateTime(double), which just uses the original Fragment::GetEnergy() call. There is a bunch of steps through here, so let me know if I missed something or for further clarification.

On Oct 23, 2015, at 5:45 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Hi guys,
The public function GetEnergy() in the TFragment class is called in GetTime() and GetTZero() respectively. So the same charge calibration procedure is potentially called several times, I don't see any benefit. Any explanation?
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544.

Space. By not storing the value directly it make the trees smaller.
Smaller trees also mean less uncompressing when doing a compiled loop over
the tree.  Compressing and uncompressing data members is really the largest
time eater in root.
Additionally, I believe Ryan is putting in some smart transient data
members which means functions like these will really only be called once
per class read.
On Oct 23, 2015 8:45 PM, "Mhd Moukaddam"<EMAIL_ADDRESS>wrote:

Hi guys,
The public function GetEnergy() in the TFragment class is called in
GetTime() and GetTZero() respectively. So the same charge calibration
procedure is potentially called several times, I don't see any benefit. Any
explanation?
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544.

He was wondering about the fragment and not the analysis I think.

On Oct 23, 2015, at 5:55 PM, pcbend<EMAIL_ADDRESS>wrote:
Space. By not storing the value directly it make the trees smaller.
Smaller trees also mean less uncompressing when doing a compiled loop over
the tree. Compressing and uncompressing data members is really the largest
time eater in root.
Additionally, I believe Ryan is putting in some smart transient data
members which means functions like these will really only be called once
per class read.
On Oct 23, 2015 8:45 PM, "Mhd Moukaddam"<EMAIL_ADDRESS>wrote:

Hi guys,
The public function GetEnergy() in the TFragment class is called in
GetTime() and GetTZero() respectively. So the same charge calibration
procedure is potentially called several times, I don't see any benefit. Any
explanation?
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544.

—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150729763.

Well may bad, I'll just keep answer random questions no one is asking than,
don't mind me. :)
On Oct 23, 2015 8:56 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

He was wondering about the fragment and not the analysis I think.

On Oct 23, 2015, at 5:55 PM, pcbend<EMAIL_ADDRESS>wrote:
Space. By not storing the value directly it make the trees smaller.
Smaller trees also mean less uncompressing when doing a compiled loop
over
the tree. Compressing and uncompressing data members is really the
largest
time eater in root.
Additionally, I believe Ryan is putting in some smart transient data
members which means functions like these will really only be called once
per class read.
On Oct 23, 2015 8:45 PM, "Mhd Moukaddam"<EMAIL_ADDRESS>wrote:

Hi guys,
The public function GetEnergy() in the TFragment class is called in
GetTime() and GetTZero() respectively. So the same charge calibration
procedure is potentially called several times, I don't see any
benefit. Any
explanation?
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544.

—
Reply to this email directly or view it on GitHub <
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150729763
.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150729846
.

Yes, but the GetEnergy() is not returning a previously calculated value, it
is actually going through the calibration procedure. So if you call
GetEnergy() in a detector class, followed by a call of GetTZero() right
after, you'd
be calibrating twice. Cheers
On Oct 23, 2015 5:54 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

I don’t think it actually is, calling GetTime() calls TChannel::GetTZero
not TFragment::GetTZero.
The Fragment calls make the GetEnergy call. but the
TChannel::GetTZero(double) then calls TChannel::CalibrateTime(double),
which just uses the original Fragment::GetEnergy() call. There is a bunch
of steps through here, so let me know if I missed something or for further
clarification.

On Oct 23, 2015, at 5:45 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Hi guys,
The public function GetEnergy() in the TFragment class is called in
GetTime() and GetTZero() respectively. So the same charge calibration
procedure is potentially called several times, I don't see any benefit. Any
explanation?
—
Reply to this email directly or view it on GitHub <
https://github.com/GRIFFINCollaboration/GRSISort/issues/544>.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150729711
.

Right, but there are two different calibrations. It only calibrates energy once, and it calibrates time once. The fragment tree does not store the real energy, nor does it store the real time. This is because the DAQ does not give us these things, so it would be against the idea of the fragment tree to put both of these in the root file. Does this make sense?

On Oct 23, 2015, at 6:07 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Yes, but the GetEnergy() is not returning a previously calculated value, it
is actually going through the calibration procedure. So if you call
GetEnergy() in a detector class, followed by a call of GetTZero() right
after, you'd
be calibrating twice. Cheers
On Oct 23, 2015 5:54 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

I don’t think it actually is, calling GetTime() calls TChannel::GetTZero
not TFragment::GetTZero.
The Fragment calls make the GetEnergy call. but the
TChannel::GetTZero(double) then calls TChannel::CalibrateTime(double),
which just uses the original Fragment::GetEnergy() call. There is a bunch
of steps through here, so let me know if I missed something or for further
clarification.

On Oct 23, 2015, at 5:45 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Hi guys,
The public function GetEnergy() in the TFragment class is called in
GetTime() and GetTZero() respectively. So the same charge calibration
procedure is potentially called several times, I don't see any benefit. Any
explanation?
—
Reply to this email directly or view it on GitHub <
https://github.com/GRIFFINCollaboration/GRSISort/issues/544>.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150729711
.

—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-150730417.

Hi Guys,
It makes total sense if it's not time consuming, and I think transient members are good  (my understanding here is that they are filled on the fly, they could be used in the calculations, but they don't have to be written in the fragment trees). I am also 100% with making the Fragment tree as basic as possible. For my own references, do you have any time estimate of the time spent by the code to calibrate?
Just to make sure my point is clear, I have planted some printf here and there and here's the result of this code snippet :

printf("---------- Calling frag.GetEnergy()\n");
energy = frag.GetEnergy();
printf("---------- finished Calling frag.GetEnergy()\n");
ts     = frag.GetTimeStamp();
printf("---------- finished Calling frag.GetTimeStamp()\n");

Output :
---------- Calling frag.GetEnergy()
TFragment::GetEnergy(int 0)
Calling chan->CalibrateENG(509201)
calling  CalibrateENG( 4073.615133 )
End of function TChannel::CalibrateENG, energy: 556.586726
---------- finished Calling frag.GetEnergy()
TFragment::GetEnergy(int 0)
Calling chan->CalibrateENG(509201)
calling  CalibrateENG( 4073.609126 )
End of function TChannel::CalibrateENG, energy: 556.586886
---------- finished Calling frag.GetTimeStamp()

I’m not sure on the time to process, but writing is so freaking slow that you would have to process >10 times to make up for writing once. The other trick (that isn’t employed in fragments) is that when you process the events once, you store the values you came up with. We haven’t put too much though into the fragment tree since it isn’t expected that you do much analysis there, just diagnostics. If you want to measure the time used during GetEnergy, try timing the difference in the call to charge.at http://charge.at/(0) vs GetEnergy. In my opinion, even if it’s 50% worse, it’s worth the HD space saved and writing time.
The difference in your results below is just because int->float conversion requires a random number to smooth it out, and in the fragment tree we don’t store the energy after calculating it, so multiple calculations will return slightly different values.

On Oct 26, 2015, at 2:09 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Hi Guys,
It makes total sense if it's not time consuming, and I think transient members are good (my understanding here is that they are filled on the fly, they could be used in the calculations, but they don't have to be written in the fragment trees). I am also 100% with making the Fragment tree as basic as possible. For my own references, do you have any time estimate of the time spent by the code to calibrate?
Just to make sure my point is clear, I have planted some printf here and there and here's the result of this code snippet :
printf("---------- Calling frag.GetEnergy()\n");
energy = frag.GetEnergy();
printf("---------- finished Calling frag.GetEnergy()\n");
ts = frag.GetTimeStamp();
printf("---------- finished Calling frag.GetTimeStamp()\n");
Output :
---------- Calling frag.GetEnergy()
TFragment::GetEnergy(int 0)
Calling chan->CalibrateENG(509201)
calling CalibrateENG( 4073.615133 )
End of function TChannel::CalibrateENG, energy: 556.586726
---------- finished Calling frag.GetEnergy()
TFragment::GetEnergy(int 0)
Calling chan->CalibrateENG(509201)
calling CalibrateENG( 4073.609126 )
End of function TChannel::CalibrateENG, energy: 556.586886
---------- finished Calling frag.GetTimeStamp()
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151231293.

Ok,
Sorry I had to make it clear that my problem is not with the energy calculation, this wasn't the point from the output I posted. Anyway, I think it's clear that you are aware of this redundant calculation...This is all I want to demonstrate. It can be easily solved by making a member (a transient-energy) in the TChannel that could be called on the fly but will not be written on HD.
(If I have time I can benchmark it with root, but I'll trust you on that. The link doesn't work by the way).
Cheers

You are correct, we could calculate energy on the fly. But then you also need write a null flag to the root file that asks whether you have calculated the energy yet. The reason is that (for a split tree) root saves time when playing back a tree by reusing the memory of the previous branch every time GetEntry is called. It then fills the memory with data from the file. This leads to the result that the current energy = the previous energy! There is no sure-fire way to check if you have recalculated the energy yet or not when doing this. This took me many hours to figure out. I got around this in the analysis tree by writing a string of bools set to 0 to disk, which are the loaded values when GetEntry is called. You can then compare against this flag. So the decision to be made is whether we care enough about the recalculations in the fragment tree to write a million zeros to disk. I plan to eventually lay this idea out somewhere on the wiki as it took me a long time to figure out, and it is, in my opinion, a very subtle problem.

On Oct 26, 2015, at 2:59 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
Ok,
Sorry I had to make it clear that my problem is not with the energy calculation, this wasn't the point from the output I posted. Anyway, I think it's clear that you are aware of this redundant calculation...This is all I want to demonstrate. It can be easily solved by making a member (a transient-energy) in the TChannel that could be called on the fly but will not be written on HD.
(If I have time I can benchmark it with root, but I'll trust you on that. The link doesn't work by the way).
Cheers
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151249167.

I see your point, I agree, it's not evident.
Sorry I'm taking your time, but here's my suggestion. I Like the TChannel class idea, and I think that the correct way to use the code is by using it as the "medium" class... The problem arise (I think) from the fact that the detector class uses the TFragment directly. And we should instead use the TChannel, that takes the TFragment in argument, and execute these functions (GetEnergy, GetTime, etc...) in strict order with one call and store all in some public data members that could be used by the detector class without conflicts.
But than again in this case a TChannel should be allocated.. I don't know how performing this is..
Cheers.

No worries about time taking! The more people who ask questions, the better the code gets and the more bugs we find!
I see what you are saying about the TChannel. The only problem I could see is that there is no way to enforce that the fragments are sent to the TChannel. I spent time looking but couldn’t find a function that was called on a TObject by the TTree (by default).  We could have done the same with the Analysis Tree, but you would have to somehow call an InitializeParams function, which is not guaranteed to always be called, especially if you are using a TTree->Draw command. You also have no way of checking that you have ever called this function in the past on your current object. You have no idea how much better ROOT life would be with a function that is called on a tree I/O. The streamer is called on every I/O if you do not split your tree, but you lose a lot of functionality by doing so. A conversation to bring up is whether we would like a “non-drawable” flag that removes the splitting of the trees. I/O would be faster, and we could save some HD space.
I should also clear up that processing time may actually not even be that much slower with the GetEnergy calculations because the I/O through the smaller file is quicker! I was shocked when my analysis script was faster while calculating these things.
I’m not sure what you mean by the DetectorHits uses the fragment class directly (there may be some, but the base detector classes shouldn’t. I’m not sure if you are on the newest version, but the DetectorHits do in fact just make their GetEnergy and GetTime calls via the TChannel. The fragment is used to set the base parameters (timestamp, charge, cfd) albeit through a very inefficient process of using DetectorData (this will be fixed soon). But the TChannel class is now what does the real work. I haven’t benchmarked it, but I honestly believe that we are probably mostly I/O limited in playback, and not in processing data anyway.
Maybe I went off on a tangent here and didn’t address your real issue. Let me know!

On Oct 26, 2015, at 5:29 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
I see your point, I agree, it's not evident.
Sorry I'm taking your time, but here's my suggestion. I Like the TChannel class idea, and I think that the correct way to use the code is by using it as the "medium" class... The problem arise (I think) from the fact that the detector class uses the TFragment directly. And we should instead use the TChannel, that takes the TFragment in argument, and execute these functions (GetEnergy, GetTime, etc...) in strict order with one call and store all in some public data members that could be used by the detector class without conflicts.
But than again in this case a TChannel should be allocated.. I don't know how performing this is..
Cheers.
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151290040.

So, I am not entirely sure I follow what you are getting at... Currently to
build a detector you need both a list of fragments and a list of channels,
of course one can always get the channel with the fragment as they are
stored by hash of the fragment address.  The look-up time of a channel from
a fragment is as small as it can be, as said earlier it is just a hash look
up.  The actual calculation of the energy from the charge is also tiny, as
it is one multiplication and one addition.  Admittedly, it can not be as
fast as just reading it if it was already stored to a file, but since we
are storing the charge to a file anyway, that read time is factored in.
Now, what I think you are concerned about is the speed need to calculate
the energy twice?   The only time this will make a noticeable difference is
when one calls TTree::Draw(), and this has to do with how the draw command
reads and stashes data.  In short, when one calls a function in a branch
member root forces the tree to read the entire class from memory instead of
just the part needed to do the calculation, this prevents the auto loop of
ttree::draw from optimizing the loop.  In compiled code, we are in a
different world; here on the GetEntry knows it has to read the entire class
from and hence plans accordingly.  Additionally, in compiled code one, the
charge is read into memory - it stays there for some time, hence additional
calls to GetEnergy are only a hash-lookup, one multiplication and one
addition, doing these three calls is on par if not faster than the time
need to look and read and unzip another 4-8 bytes from the root branch.
Unzipping is very slow by computer standards.
Now, I guess you are suggesting to Chain the GetEnergy and GetTime
together.  In all reality, this might help a bit - depending on how things
are stored.  But in all reality GetTime is only needed on the Ge arrays, as
they are the one that have funny rise times we are trying to over come.
And, at least six months ago, Tigress was triggering on cfd which made the
correction mostly irrelevant.  Meaning this is really on a Griffin issue.
On Mon, Oct 26, 2015 at 5:29 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:

I see your point, I agree, it's not evident.
Sorry I'm taking your time, but here's my suggestion. I Like the TChannel
class idea, and I think that the correct way to use the code is by using it
as the "medium" class... The problem arise (I think) from the fact that the
detector class uses the TFragment directly. And we should instead use the
TChannel, that takes the TFragment in argument, and execute these functions
(GetEnergy, GetTime, etc...) in strict order with one call and store all in
some public data members that could be used by the detector class without
conflicts.
But than again in this case a TChannel should be allocated.. I don't know
how performing this is..
Cheers.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151290040
.

Peter, it shocked me, but reading charge and energy from file is slower than reading charge and calculating energy. RAM beats root decompression!

On Oct 26, 2015, at 5:59 PM, pcbend<EMAIL_ADDRESS>wrote:
So, I am not entirely sure I follow what you are getting at... Currently to
build a detector you need both a list of fragments and a list of channels,
of course one can always get the channel with the fragment as they are
stored by hash of the fragment address. The look-up time of a channel from
a fragment is as small as it can be, as said earlier it is just a hash look
up. The actual calculation of the energy from the charge is also tiny, as
it is one multiplication and one addition. Admittedly, it can not be as
fast as just reading it if it was already stored to a file, but since we
are storing the charge to a file anyway, that read time is factored in.
Now, what I think you are concerned about is the speed need to calculate
the energy twice? The only time this will make a noticeable difference is
when one calls TTree::Draw(), and this has to do with how the draw command
reads and stashes data. In short, when one calls a function in a branch
member root forces the tree to read the entire class from memory instead of
just the part needed to do the calculation, this prevents the auto loop of
ttree::draw from optimizing the loop.  In compiled code, we are in a
different world; here on the GetEntry knows it has to read the entire class
from and hence plans accordingly. Additionally, in compiled code one, the
charge is read into memory - it stays there for some time, hence additional
calls to GetEnergy are only a hash-lookup, one multiplication and one
addition, doing these three calls is on par if not faster than the time
need to look and read and unzip another 4-8 bytes from the root branch.
Unzipping is very slow by computer standards.
Now, I guess you are suggesting to Chain the GetEnergy and GetTime
together. In all reality, this might help a bit - depending on how things
are stored. But in all reality GetTime is only needed on the Ge arrays, as
they are the one that have funny rise times we are trying to over come.
And, at least six months ago, Tigress was triggering on cfd which made the
correction mostly irrelevant. Meaning this is really on a Griffin issue.
On Mon, Oct 26, 2015 at 5:29 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:

I see your point, I agree, it's not evident.
Sorry I'm taking your time, but here's my suggestion. I Like the TChannel
class idea, and I think that the correct way to use the code is by using it
as the "medium" class... The problem arise (I think) from the fact that the
detector class uses the TFragment directly. And we should instead use the
TChannel, that takes the TFragment in argument, and execute these functions
(GetEnergy, GetTime, etc...) in strict order with one call and store all in
some public data members that could be used by the detector class without
conflicts.
But than again in this case a TChannel should be allocated.. I don't know
how performing this is..
Cheers.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151290040
.

—
Reply to this email directly or view it on GitHub.

Blame it on the 19 hour days, I hope thats what a said... except when using
the Draw command.  I am glad you are here to back me up one this one. :)
On Mon, Oct 26, 2015 at 6:03 PM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Peter, it shocked me, but reading charge and energy from file is slower
than reading charge and calculating energy. RAM beats root decompression!

On Oct 26, 2015, at 5:59 PM, pcbend<EMAIL_ADDRESS>wrote:
So, I am not entirely sure I follow what you are getting at... Currently
to
build a detector you need both a list of fragments and a list of
channels,
of course one can always get the channel with the fragment as they are
stored by hash of the fragment address. The look-up time of a channel
from
a fragment is as small as it can be, as said earlier it is just a hash
look
up. The actual calculation of the energy from the charge is also tiny,
as
it is one multiplication and one addition. Admittedly, it can not be as
fast as just reading it if it was already stored to a file, but since we
are storing the charge to a file anyway, that read time is factored in.
Now, what I think you are concerned about is the speed need to calculate
the energy twice? The only time this will make a noticeable difference
is
when one calls TTree::Draw(), and this has to do with how the draw
command
reads and stashes data. In short, when one calls a function in a branch
member root forces the tree to read the entire class from memory instead
of
just the part needed to do the calculation, this prevents the auto loop
of
ttree::draw from optimizing the loop. In compiled code, we are in a
different world; here on the GetEntry knows it has to read the entire
class
from and hence plans accordingly. Additionally, in compiled code one,
the
charge is read into memory - it stays there for some time, hence
additional
calls to GetEnergy are only a hash-lookup, one multiplication and one
addition, doing these three calls is on par if not faster than the time
need to look and read and unzip another 4-8 bytes from the root branch.
Unzipping is very slow by computer standards.
Now, I guess you are suggesting to Chain the GetEnergy and GetTime
together. In all reality, this might help a bit - depending on how
things
are stored. But in all reality GetTime is only needed on the Ge arrays,
as
they are the one that have funny rise times we are trying to over come.
And, at least six months ago, Tigress was triggering on cfd which made
the
correction mostly irrelevant. Meaning this is really on a Griffin issue.
On Mon, Oct 26, 2015 at 5:29 PM, Mhd Moukaddam<EMAIL_ADDRESS>

wrote:

I see your point, I agree, it's not evident.
Sorry I'm taking your time, but here's my suggestion. I Like the
TChannel
class idea, and I think that the correct way to use the code is by
using it
as the "medium" class... The problem arise (I think) from the fact
that the
detector class uses the TFragment directly. And we should instead use
the
TChannel, that takes the TFragment in argument, and execute these
functions
(GetEnergy, GetTime, etc...) in strict order with one call and store
all in
some public data members that could be used by the detector class
without
conflicts.
But than again in this case a TChannel should be allocated.. I don't
know
how performing this is..
Cheers.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151290040>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/544#issuecomment-151297267
.

If it's only on the Draw command than it should not be a big issue, in my opinion it is only relevant if the user can win time by suppressing redundancy, if this is possible of course.
The other thing is, I am using a code that is old, but whether it's old or not the I think the functions of the TFragment will still be similar.
This is how the calibrated data is set in the Hit Class:

void SetVariables(TFragment &frag) { charge = frag.GetCharge();
energy = frag.GetEnergy();
ts     = frag.GetTimeStamp();  // this one calls the frag.GetEnergy() again...
time   = frag.GetZCross();
cfd    = frag.GetCfd();
}

I think the code will always look somehow similar to that, i.e. getting the calibrated info from the TFragment directly. what I was suggesting/exploring was to get the calibrated data, from the TChannel.  The TChannel is more like a procedure class, and is not written to the hard drive anyway, however it has all the calibration coefficients, and it could have an extra procedure execute any set of functions in an certain order to avoid any redundancy, and store the values in its own public member. This of course means that the TFragment should be regarded as a very basic structure (some sort of a ROOT version of the MIDAS file).
But again if you think there's no win, than it is not a problem at all.
Cheers

I think we are doing exactly as you suggest. There just isn't a function that sets everything at the same time. It doesn't really help anyway because you still need to know you did something so you need flags.
The code has changed quite a bit. Since we branched off 5 or 6 months ago. We also have or will be removing any non basic data setting from the building in the analysis tree. So you aren't calibrating on the build anyway.

On Oct 26, 2015, at 6:55 PM, Mhd Moukaddam<EMAIL_ADDRESS>wrote:
If it's only on the Draw command than it should not be a big issue, in my opinion it is only relevant if the user can win time by suppressing redundancy, if this is possible of course.
The other thing is, I am using a code that is old, but whether it's old or not the I think the functions of the TFragment will still be similar.
This is how the calibrated data is set in the Hit Class:
void SetVariables(TFragment &frag) { charge = frag.GetCharge();
energy = frag.GetEnergy();
ts = frag.GetTimeStamp(); // this one calls the frag.GetEnergy() again...
time = frag.GetZCross();
cfd = frag.GetCfd();
}
I think the code will always look somehow similar to that, i.e. getting the calibrated info from the TFragment directly. what I was suggesting/exploring was to get the calibrated data, from the TChannel. The TChannel is more like a procedure class, and is not written to the hard drive anyway, however it has all the calibration coefficients, and it could have an extra procedure execute any set of functions in an certain order to avoid any redundancy, and store the values in its own public member. This of course means that the TFragment should be regarded as a very basic structure (some sort of a ROOT version of the MIDAS file).
But again if you think there's no win, than it is not a problem at all.
Cheers
—
Reply to this email directly or view it on GitHub.

ok, I will update when you guys finish the hard work on the design and when I finish some other routines that could be translated directly into the new code.
Cheers.

Here is a snapshot of what I think you are talking about in the new Hit class.
Double_t TGRSIDetectorHit::GetTime(Option_t *opt) {
   if(IsTimeSet())
      return ftime;

   Double_t dtime = static_cast<Double_t>((GetTimeStamp()) + gRandom->Uniform());
   TChannel *chan = GetChannel();
   if(!chan)
      return dtime;

   SetTime(dtime-chan->GetTZero(GetEnergy()));

   return ftime;
}

double TGRSIDetectorHit::GetEnergy(Option_t *opt){
   if(IsEnergySet()){
      return fenergy;
   }

   TChannel *chan = GetChannel();
   if(!chan){
      printf("no TChannel set for this address\n");
      return 0.00;
   }
      SetEnergy(chan->CalibrateENG(GetCharge()));
      return fenergy;

}

This runs reasonably fast, and only calibrates the energy once. The charge would (will) be set during something like
void TGRSIDetectorHit::SetVariables(TFragment &frag) {
fcharge = frag.GetCharge();
ftimestamp = frag.GetTimeStamp();
...
}
Is this what you are talking about?

@VinzenzBildstein is working on making the second part work for all of the detectors. I'm not sure exactly how he is doing it, but it should be done soon.

Neat!
this is exactly what I'm talking about.
Cheers.


Add docker registry operator

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Prow preset was broken, rerunning job


ServerChangeScene sends NotReadyMessage to non-authenticated-yet connections

Describe the bug
If you call ServerChangeScene(), it'll call NetworkServer.SetAllClientsNotReady() which sends NotReadyMessage to all clients:
foreach (NetworkConnectionToClient conn in connections.Values)
{
    SetClientNotReady(conn);
}

Even for those who hasn't authenticated yet! That's kind of strange. Because NotReadyMessage is a message for authenticated clients only, calling ServerChangeScene() when there're non-authenticated clients on the server would disconnect them:
Disconnecting connection: connection(0). Received message Mirror.NotReadyMessage that required authentication, but the user has not authenticated yet
UnityEngine.Debug:LogWarning (object)

I'm rewriting the way my game loads and connects to servers, but this problem has appeared. I was wondering why when the online scene is set and there's definitely a ServerChangeScene() call, everything works good and even when the host player isn't authenticated yet. Now, as I understand, it's because of the order in StartHost():
if (IsServerOnlineSceneChangeNeeded())
{
    // call FinishStartHost after changing scene.
    finishStartHostPending = true;
    ServerChangeScene(onlineScene);
}
// otherwise call FinishStartHost directly
else
{
    FinishStartHost();
}

FinishStartHost() will add the host player to the list, which will be called much more later (after the scene is loaded). So ServerChangeScene() will not send the message to the host player. But when there's no online scene, FInishStartHost() will immediately add the host player, even before StartHost() stops executing.
And now after StartHost() when there's no online scene, I try to change scene with ServerChangeScene() and... there's already added host player, it's not authenticated yet... and the host client is disconnected. 👍
[IMPORTANT] How can we reproduce the issue, step by step:

You need a network manager with an authenticator set, so the host won't be authenticated immediately.
The manager should have no online scene set.
Then you call NetworkManager.StartHost();
Immediately after it, you try to change scene to another one: NetworkManager.ServerChangeScene(randomScene);
Then, maybe after some time the exception will be thrown, that will disconnect the host player.

Expected behavior
SetAllClientsNotReady() shouldn't set non-authenticated players not ready.
Desktop (please complete the following information):

OS: Windows
Build target: Windows (tested in the editor though)
Unity version: 2022.3.20f1
Mirror branch: uhm.. master I think. Downloaded from asset store (81.4.0 (but it seems like the code works the same like in the master branch now))

Idk maybe it should be something like this:
public static void SetAllClientsNotReady()
{
    foreach (NetworkConnectionToClient conn in connections.Values)
    {
        if (!conn.isAuthenticated)
            continue;

        SetClientNotReady(conn);
    }
}

This was already fixed in Mirror 89.0.0.
See ChangeLog.


Create a ur_modern_driver_tools package

To host contributions like the convenience functions that were originally part of #247.
It should host scripts (and perhaps nodes) that are not directly part of the driver, but would still be useful to keep close to the driver.
Making this a separate package would allow the use of such tools without having to install/build the driver itself as well.

@felixvd added wait_for_program.h  in #247, which would be a good first candidate for the package.

test_move.py would be another candidate (not this version specifically though).

Not particularly against this, but we need to choose when to do it wisely, since moving current content into a sub-folder will conflict with all open PRs.

I'm closing this as we've officially deprecated this package.
Refer to the announcement on ROS Discourse.

@felixvd: it may make sense to see whether your convenience function could be updated to be used with ur_robot_driver. If it can, please open an issue on the ur_robot_driver issue tracker to discuss where it should be hosted.
If you'd be interested of course.


mkspiffs: init at 0.2.3

Motivation for this change
There wasn't a derivation for mkspiffs yet, so I made one.
Supersedes #46623 as it does, besides the generic version, also contain the versions for arduino-esp32, arduino-esp8266 and esp-idf.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build mkspiffs mkspiffs-presets.arduino-esp8266 mkspiffs-presets.arduino-esp32 mkspiffs-presets.esp-idf

Success on x86_64-linux (full log)
Attempted: mkspiffs, mkspiffs-presets.arduino-esp8266, mkspiffs-presets.arduino-esp32, mkspiffs-presets.esp-idf
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3
shrinking /nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3/bin/mkspiffs
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3/bin
patching script interpreter paths in /nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3
checking for references to /build in /nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3...
/nix/store/jxs1rd5n7g1gha3x8d7sfzj8qpi2ga5b-mkspiffs-0.2.3
/nix/store/kvdvw2ky489rjz00ngrzxg0va9kijr5v-mkspiffs-0.2.3
/nix/store/ngx3n33v4lnd6r22phzfds8cpy5qhf7c-mkspiffs-0.2.3
/nix/store/ji2x8i36ywxyxmqwy8wak5m42fykz2b6-mkspiffs-0.2.3

Failure on x86_64-darwin (full log)
Attempted: mkspiffs, mkspiffs-presets.arduino-esp8266, mkspiffs-presets.arduino-esp32, mkspiffs-presets.esp-idf
Partial log (click to expand)
      _spiffs_object_create in spiffs_nucleus.o
      _spiffs_object_update_index_hdr in spiffs_nucleus.o
  "start", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture i386
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:106: mkspiffs] Error 1
builder for '/nix/store/93qih1v1wmkv812zrsfb2yldfk1398f1-mkspiffs-0.2.3.drv' failed with exit code 2
builder for '/nix/store/x8c30s9216yczz90f0jafab0p20j53dj-mkspiffs-0.2.3.drv' failed with exit code 2
error: build of '/nix/store/145akjfyrcd7nbphr8a0vimg44499iz1-mkspiffs-0.2.3.drv', '/nix/store/93qih1v1wmkv812zrsfb2yldfk1398f1-mkspiffs-0.2.3.drv', '/nix/store/qv3k2rbsg737xcgd6pzl3n9v0bwwwfhy-mkspiffs-0.2.3.drv', '/nix/store/x8c30s9216yczz90f0jafab0p20j53dj-mkspiffs-0.2.3.drv' failed

Success on aarch64-linux (full log)
Attempted: mkspiffs, mkspiffs-presets.arduino-esp8266, mkspiffs-presets.arduino-esp32, mkspiffs-presets.esp-idf
Partial log (click to expand)
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/d8rcj9miyf6camdwvx87wn74n5xcdlng-mkspiffs-0.2.3/bin
patching script interpreter paths in /nix/store/d8rcj9miyf6camdwvx87wn74n5xcdlng-mkspiffs-0.2.3
patching script interpreter paths in /nix/store/jlvr0smc2kj4f5m6xkc8h7wg1z3rhhyd-mkspiffs-0.2.3
checking for references to /build in /nix/store/jlvr0smc2kj4f5m6xkc8h7wg1z3rhhyd-mkspiffs-0.2.3...
checking for references to /build in /nix/store/d8rcj9miyf6camdwvx87wn74n5xcdlng-mkspiffs-0.2.3...
/nix/store/cr6n6d8qg0kp3lnbjrcyvl7y9ji77vsd-mkspiffs-0.2.3
/nix/store/92y0llfm9pqcv2rp3binal0jdp92l0lf-mkspiffs-0.2.3
/nix/store/d8rcj9miyf6camdwvx87wn74n5xcdlng-mkspiffs-0.2.3
/nix/store/jlvr0smc2kj4f5m6xkc8h7wg1z3rhhyd-mkspiffs-0.2.3

If you happen to know how to fix the darwin failure that would be nice. If not, you should disable darwin (maybe set meta.platforms = platforms.linux)

If you happen to know how to fix the darwin failure that would be nice. If not, you should disable darwin (maybe set meta.platforms = platforms.linux)

I currently don't know how to fix the failure, so I added the suggested code.

(triage) The concerns from @Infinisil appear to have been taken care of, this looks ready to me. Triggering a build just in case.
@GrahamcOfBorg build mkspiffs mkspiffs-presets.arduino-esp8266 mkspiffs-presets.arduino-esp32 mkspiffs-presets.esp-idf

Success on aarch64-linux (full log)
Attempted: mkspiffs, mkspiffs-presets.arduino-esp8266, mkspiffs-presets.arduino-esp32, mkspiffs-presets.esp-idf
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3
shrinking /nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3/bin/mkspiffs
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3/bin
patching script interpreter paths in /nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3
checking for references to /build in /nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3...
/nix/store/ysp2rshi2qzvhg8kz9ijssh9mi90xsnr-mkspiffs-0.2.3
/nix/store/79z6vn5wk9v1nzrijkin5nqdz8bk13x2-mkspiffs-0.2.3
/nix/store/xiy132mplnjqp3cm4drjlp27zi6wb3iv-mkspiffs-0.2.3
/nix/store/g3cbn2bh54xwd06jgl2n0q8a87lsq9nh-mkspiffs-0.2.3

Success on x86_64-linux (full log)
Attempted: mkspiffs, mkspiffs-presets.arduino-esp8266, mkspiffs-presets.arduino-esp32, mkspiffs-presets.esp-idf
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3
shrinking /nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3/bin/mkspiffs
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3/bin
patching script interpreter paths in /nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3
checking for references to /build in /nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3...
/nix/store/qcf1gyingyvfwvw2j80927x1rshfpm5g-mkspiffs-0.2.3
/nix/store/f6z5g0lcyrfp6nrn30vf48wxgan4njr3-mkspiffs-0.2.3
/nix/store/qrd0k8zv3bfaap0657rskbzvfy97ghkm-mkspiffs-0.2.3
/nix/store/qhikr38fxc141kyam6z02g3p7s8vwikr-mkspiffs-0.2.3


Train button does not work

From report in community forum: https://community.almond.stanford.edu/t/training-almond/155

Train appears to be working in simple testing. I think what might be happening here is that the server returns no choices for a specific command, so the list of options to train with is empty.


V3.10 Add support for Windows 10 UWP and Windows 8.1 Universal Apps

This PR adds the project files for building the samples for Windows 10 UWP and Windows 8.1 Universal  apps.

@stammen Thanks. I will bring this down in the next few days locally and test it. I have other changes to do for the samples as well. We really appreciate the effort. Thank you.

@slackmoehrle Why was this never pulled?

@stammen I haven't made it to it yet. I'll make time for this. I apologize.

Thanks for the update


docs/fix: missing "to" infinitive marker

Add a missing "to" infinitive marker.

@allcontributors please add @kyarik for doc


M1 pre-built binary

Feature
Add pre-built binaries for M1 and other arm architectures. The following message occurs when running intall.sh on a 2020 macbook pro. I see aarch64 is already available in the github workflow so perhaps only aarch64-apple-darwin is needed.
curl https://wasmtime.dev/install.sh -sSf | bash

Error: Sorry! Wasmtime currently only provides pre-built binaries for x86_64 architectures.

Benefit
The demand for m1 support will only grow with time.
Implementation
It looks like we only need to add a cross-compile target in the github workflow.
I searched for arm related github issues and only found a few

https://github.com/bytecodealliance/wasmtime/issues/2808
https://github.com/bytecodealliance/wasmtime/issues/2127
https://github.com/bytecodealliance/wasmtime/issues/2907
https://github.com/bytecodealliance/wasmtime/issues/2735

IMO the above bugs shouldn't prevent releasing a binary.

We've now released Wasmtime 0.37, which includes the change in #3983 to build aarch64-apple-darwin binaries, and just now we added the platform to the install.sh script at wasmtime.dev (bytecodealliance/wasmtime.dev#13). Given that, I think we can call this complete and close it!


Change target-bigquery default variant to one of the SDK based ones

I think we should make https://hub.meltano.com/loaders/target-bigquery--youcruit/ (showcased in https://meltano.com/blog/6x-more-speed-for-your-data-pipelines-with-batch-messages/) or https://hub.meltano.com/loaders/target-bigquery--z3z1ma/ (By Alex @ Harness) the default target-bigquery variant as it’s built with the SDK and supports BATCH.

This is a good idea especially because we've seen a fair amount of users hit hard failures in the adswerve variant due to data types and it doesnt look like theyre prioritizing supporting a fail safe type https://github.com/adswerve/target-bigquery/issues/35.
I'm not sure how we decide which variant becomes default out of the 2 SDK based versions. It seems like Alex has tried to build a more feature rich/optimized version so from a surface level exploration I'd probably vote for that one but clearly the youcruit version is good as well based on the blog post. I wonder if we should ask them directly if either want to consolidate effort on one of the variants, or volunteer to not be default. We could also ask the community to weigh in on this if they have experience with either.

I'm generally supportive - hard to say if there are any critical missing features from an SDK-based one. But if folks are feeling confident we can make the switch.


Models other than gpt-3.5-turbo result in fault

Bug description
Toggling the model for gpt-4, or 3, or any variant thereof in PyCharm  gives the error:
"the model <> does not exist"
aicommits version
2.2.1
Environment
Windows 10 2023.1.2
Pycharm: PC-231.9011.38
Version 2023.1.2
PyCharm 2023.1.2 (Community Edition)
Build #PC-231.9011.38, built on May 16, 2023
Runtime version: 17.0.6+10-b829.9 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 4
Registry:
    ide.balloon.shadow.size=0

Can you contribute a fix?

[ ] I’m interested in opening a pull request for this issue.

PyCharm? Is this the right project?

Perhaps not? Please close this issue.


Nicer up output

Temporary stuff for now. Ideally we have upload progress etc, per-region and whatnot, copy to clip.

refactored with a channel of events to fully decouple


How can I set column width and background color in alasql  with js-xlsx library

It can be easily done if I have one tab then I can do this using XLSXML() renderer but how can I do this with XLSX() where I have multiple tabs

I dont think this can be done

is there any other way through which I can manipulate the width of columns if I have multiple tabs in my excel sheet?

Have a look at the documentation of https://github.com/SheetJS/js-xls


hosting site using dotnet publish gave 500 Internal server error.

Web App uses RC2. According to this link https://github.com/aspnet/Announcements/issues/164
we might need to use core module instead of HttpPlatformHandler.
from where can i get the following package "Microsoft.AspNetCore.Server.IISIntegration".

You can look at the feeds on cli-samples https://github.com/aspnet/cli-samples/blob/master/NuGet.Config

installed asp.net core x64 module.
added the following dependency "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0-rc2-*"
modified my startup.cs

modified the web.config

publish folder using dotnet publish

copied the contents of publish folder in a c:/inetpub/wwwroot/IdpWebApp

createa a webapplication and pointed to wwwroot of publish folder

Browsing the site gave me 500 internal server error

checked event  viewer.It shows Asp.net core module started successfully.

What's missing here.

You're pretty close actually, that's the Asp.Net startup error page. It means there was an exception starting your app, probably from the Startup class. If you set ASPNETCORE_ENVIRONMENT to Development you should get the details. The easiest place to set this is in the Web.Config, aspNetCore has an environment variables sub-section.

my hosting environment is

@ibrmohammed You're not following the cli-samples project. Check out https://github.com/aspnet/cli-samples/tree/master/HelloMvc ... unless you were specifically trying to setup a standalone application; the cli-samples follow the shared framework model.

the framework in my project is
"frameworks": {
"net451": { }
},

That's fine, but were you trying to setup a standalone (self-contained) application or a shared framework application?  If you didn't know about the difference between the two application types, you can read more here: https://github.com/blackdwarf/core-docs/blob/clidocs/docs/core-concepts/app-types.md
The cli-samples are all shared framework projects. If you want to see one that's a standalone project, I have a test project of mine in my repo at: https://github.com/GuardRex/standalone ... the standalone project would be restored the same way, dotnet restore but published with the RID: dotnet publish --configuration Release --runtime win81-x64.

i think its a shared framework because of the dependencies

You need to depend on ..
"Microsoft.NETCore.App": {
  "type": "platform",
  "version": "1.0.0-*"
}

... for it to be a shared framework app. It's the "type": "platform" part that makes it shared.

So you mean to say its a standalone application.And what does win 81-x64 suggests?

the command that i used to publish the application was this
dotnet publish "src\Aps.Idp.Web" -c "Release"  -f "net451" -o "artifacts\bin\Aps.Idp.Web\Release\PublishOutput"

That's the runtime id (RID). win81-x64 is appropriate for Windows 8.1+/Windows Server 2012/R2+.
Add the runtimes section to project.json with the win81-x64 RID, and add -r win81-x64 to your publish command. You should get proper ouput.
There may be a few other issues here to address though:

web.config has the correct paths for the .exe and log file
the "Microsoft.NETCore.DotNetHostPolicy": "1.0.1-*" package dep
web.config is in the content root (the application base path)
web.config added to the content section of project.json
NuGet.config is pointed to the aspnetcirelease feed and api.nuget.org feed.

There are a lot of little things to check. Compare your app to my standalone for the general layout.

Is that the publish folder for standalone app
https://github.com/ibrmohammed/standalone

No, it will publish deep within the bin folder ... you'll see a publish folder in there. That will contain the bits you need to deploy. See the full layout here: https://github.com/dotnet/cli/issues/937#issuecomment-186737388

Ah !! My bad.Its the project.
can you give me the publish folder for the standalone app.so that i can get a better understanding.

Just publish that one ... run dotnet restore on it, then do a ...
dotnet publish --configuration Release --runtime win81-x64

... It will create the full outputs for you, and you'll see the publish folder in there. The contents of that folder is what you deploy to the server.

@GuardRex
From the points mentioned above. I did not get your 3rd point.what change should i have to do for point 3?
1.web.config has the correct paths for the .exe and log file
2.the "Microsoft.NETCore.DotNetHostPolicy": "1.0.1-*" package dep
3.web.config is in the content root (the application base path)
4.web.config added to the content section of project.json
5.NuGet.config is pointed to the aspnetcirelease feed and api.nuget.org feed.

web.config will exist at the application base path along with the rest of
the project's files.
You can also have no web.config in the project and use the publish-iis tool
to generate one for you as the cli samples show and is discussed here:
https://github.com/aspnet/IISIntegration/issues/105#issuecomment-212519337
On Apr 20, 2016 12:24 PM, "ibrmohammed"<EMAIL_ADDRESS>wrote:

@GuardRex https://github.com/GuardRex
From the points mentioned above. I did not get your 3rd point.what change
should i have to do for point 3?
1.web.config has the correct paths for the .exe and log file
2.the "Microsoft.NETCore.DotNetHostPolicy": "1.0.1-*" package dep
3.web.config is in the content root (the application base path)
4.web.config added to the content section of project.json
5.NuGet.config is pointed to the aspnetcirelease feed and api.nuget.org
feed.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Hosting/issues/711#issuecomment-212523282

@GuardRex  for the standalone app, the feed used is aspnetcirelease feed.Is this using "dnx-clr-win-x<IP_ADDRESS>-rc2-20221"
the feed i am using is https://www.myget.org/F/aspnetcidev/
My application is using "dnx-clr-win-x<IP_ADDRESS>-rc2-20222".
framework net451
Included runtimes as win81-x64 in project.json and tried dotnet restore. But the restore failed.
then tried dnu restore.Again the restore failed.
Now removed run times section from project.json and tried dnu restore.it was successfull.
But dotnet publish gave a  publish folder with  win7-x64.Upon hosting on IIS gives "Http 403.14"

@ibrmohammed No, DNX is dead. dotnet cli totally takes over. You should be using this: https://github.com/dotnet/cli/tree/rel/1.0.0

May i know if this  dnx clr version or cli version.

@ibrmohammed ... no ... none of that matters. dotnet cli is a totally different runtime, build, and tooling system. All of that is :skull: dead :skull:. The only value to it at all is for use with Visual Studio to get Intellisence. Visual Studio will get a tooling update when RC2 releases in a few weeks. You can leave those runtimes there for now, but when RC2 releases, you'll be able to delete all of the DNX stuff (including those runtimes) from your machine. If you want to work with dotnet cli, you'll be using the commands shown in the dotnet cli repo and the docs there.
You would probably be better off with VS Code. Install the "Insiders Edition," and use that until the updated Visual Studio comes out in a few weeks. To make your life with it a little easier, you can try out my Status Bar Tasks extension.

getting the following error while trying to publish using dotnet publish

"frameworks": {
"net451": { }
}

@ibrmohammed File a bug on github.com/dotnet/cli

modified my project.json
{
"userSecretsId": "aspnet5-Idp-149e9283-fb72-416b-bf12-4bc1df27d486",
"version": "1.0.0-*",
"description": "Aps.Idp.Web Project",
"authors": [ "IPPCS" ],
"commands": {
"web": "Aps.Idp.Web",
"ef": "EntityFrameworkCore.Commands"
},
"content": [
"wwwroot",
"web.config"
],
"compilationOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"exclude": [
"wwwroot",
"node_modules"
],
"frameworks": {
"net451": { },
"netcoreapp1.0": {
}

},
"dependencies": {
"Aps.Idp": "1.0.0-",
"Aps.Idp.Repository": "1.0.0-",
"Aps.Idp.Repository.EF": "1.0.0-",
"Microsoft.AspNetCore.Authentication.JwtBearer": "1.0.0-rc2-",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0-",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0-rc2-",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-",
"Microsoft.Extensions.Logging.Debug": "1.0.0-rc2-",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0-rc2-",
"Microsoft.AspNetCore.Diagnostics": "1.0.0-rc2-",
"Microsoft.NETCore.DotNetHostPolicy": "1.0.1-*"
},
"runtimes": {
"win81-x64": { }
},
"publishExclude": [
".user",
".vspscc"
],
"scripts": {
"prepublish": [ "npm install", "bower install", "gulp clean", "gulp min" ]
}
}
got the following errors when i ran a dotnet restore
log  : Restore failed in 6061ms.
Errors in C:\Users\ibrmohammed\Source\Workspaces\SbmAps\Idp\src\Aps.Idp.Web\proj
ect.json
Package Ix-Async 1.2.5 is not compatible with netcoreapp1.0 (.NETCoreApp,Ver
sion=v1.0). Package Ix-Async 1.2.5 supports:
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
Package Remotion.Linq 2.0.2 is not compatible with netcoreapp1.0 (.NETCoreAp
p,Version=v1.0). Package Remotion.Linq 2.0.2 supports:
- net35 (.NETFramework,Version=v3.5)
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile
259)
Package Newtonsoft.Json 8.0.3 is not compatible with netcoreapp1.0 (.NETCore
App,Version=v1.0). Package Newtonsoft.Json 8.0.3 supports:
- net20 (.NETFramework,Version=v2.0)
- net35 (.NETFramework,Version=v3.5)
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-dnxcore50+net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profi
le=net45+wp80+win8+wpa81+dnxcore50)
- portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Pro
file328)
One or more packages are incompatible with .NETCoreApp,Version=v1.0.
Package Ix-Async 1.2.5 is not compatible with netcoreapp1.0 (.NETCoreApp,Ver
sion=v1.0) / win81-x64. Package Ix-Async 1.2.5 supports:
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
Package Remotion.Linq 2.0.2 is not compatible with netcoreapp1.0 (.NETCoreAp
p,Version=v1.0) / win81-x64. Package Remotion.Linq 2.0.2 supports:
- net35 (.NETFramework,Version=v3.5)
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile
259)
Package Newtonsoft.Json 8.0.3 is not compatible with netcoreapp1.0 (.NETCore
App,Version=v1.0) / win81-x64. Package Newtonsoft.Json 8.0.3 supports:
- net20 (.NETFramework,Version=v2.0)
- net35 (.NETFramework,Version=v3.5)
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-dnxcore50+net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profi
le=net45+wp80+win8+wpa81+dnxcore50)
- portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Pro
file328)
System.Security.Principal.Windows 4.0.0-rc2-24018 provides a compile-time re
ference assembly for System.Security.Principal.Windows on .NETCoreApp,Version=v1
.0, but there is no run-time assembly compatible with win81-x64.
System.Collections 4.0.11-rc2-24018 provides a compile-time reference assemb
ly for System.Collections on .NETCoreApp,Version=v1.0, but there is no run-time
assembly compatible with win81-x64.
System.Diagnostics.Debug 4.0.11-rc2-24018 provides a compile-time reference
assembly for System.Diagnostics.Debug on .NETCoreApp,Version=v1.0, but there is
no run-time assembly compatible with win81-x64.
System.Globalization 4.0.11-rc2-24018 provides a compile-time reference asse
mbly for System.Globalization on .NETCoreApp,Version=v1.0, but there is no run-t
ime assembly compatible with win81-x64.
System.IO 4.1.0-rc2-24018 provides a compile-time reference assembly for Sys
tem.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible
with win81-x64.

System.Runtime.Extensions 4.1.0-rc2-24018 provides a compile-time reference
assembly for System.Runtime.Extensions on .NETCoreApp,Version=v1.0, but there is
no run-time assembly compatible with win81-x64.
System.Runtime.InteropServices 4.1.0-rc2-24018 provides a compile-time refer
ence assembly for System.Runtime.InteropServices on .NETCoreApp,Version=v1.0, bu
t there is no run-time assembly compatible with win81-x64.
System.Text.Encoding 4.0.11-rc2-24018 provides a compile-time reference asse
mbly for System.Text.Encoding on .NETCoreApp,Version=v1.0, but there is no run-t
ime assembly compatible with win81-x64.
System.Threading.Tasks 4.0.11-rc2-24018 provides a compile-time reference as
sembly for System.Threading.Tasks on .NETCoreApp,Version=v1.0, but there is no r
un-time assembly compatible with win81-x64.

System.Console 4.0.0-rc2-24018 provides a compile-time reference assembly fo
r System.Console on .NETCoreApp,Version=v1.0, but there is no run-time assembly
compatible with win81-x64.
System.Reflection.Extensions 4.0.1-rc2-24018 provides a compile-time referen
ce assembly for System.Reflection.Extensions on .NETCoreApp,Version=v1.0, but th
ere is no run-time assembly compatible with win81-x64.
System.Data.SqlClient 4.1.0-rc2-24018 provides a compile-time reference asse
mbly for System.Data.SqlClient on .NETCoreApp,Version=v1.0, but there is no run-
time assembly compatible with win81-x64.

System.Resources.ResourceManager 4.0.1-rc2-24018 provides a compile-time ref
erence assembly for System.Resources.ResourceManager on .NETCoreApp,Version=v1.0
, but there is no run-time assembly compatible with win81-x64.
System.Runtime 4.1.0-rc2-24018 provides a compile-time reference assembly fo
r System.Runtime on .NETCoreApp,Version=v1.0, but there is no run-time assembly
compatible with win81-x64.

System.IO.FileSystem 4.0.1-rc2-24018 provides a compile-time reference assem
bly for System.IO.FileSystem on .NETCoreApp,Version=v1.0, but there is no run-ti
me assembly compatible with win81-x64.
System.Reflection.Primitives 4.0.1-rc2-24018 provides a compile-time referen
ce assembly for System.Reflection.Primitives on .NETCoreApp,Version=v1.0, but th
ere is no run-time assembly compatible with win81-x64.
System.Diagnostics.Tracing 4.1.0-rc2-24018 provides a compile-time reference
assembly for System.Diagnostics.Tracing on .NETCoreApp,Version=v1.0, but there
is no run-time assembly compatible with win81-x64.
System.Security.Cryptography.Algorithms 4.1.0-rc2-24018 provides a compile-t
ime reference assembly for System.Security.Cryptography.Algorithms on .NETCoreAp
p,Version=v1.0, but there is no run-time assembly compatible with win81-x64.
System.Text.Encoding.Extensions 4.0.11-rc2-24018 provides a compile-time ref
erence assembly for System.Text.Encoding.Extensions on .NETCoreApp,Version=v1.0,
but there is no run-time assembly compatible with win81-x64.
System.Runtime.InteropServices.RuntimeInformation 4.0.0-rc2-24018 provides a
compile-time reference assembly for System.Runtime.InteropServices.RuntimeInfor
mation on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible
with win81-x64.
System.Security.Cryptography.X509Certificates 4.1.0-rc2-24018 provides a com
pile-time reference assembly for System.Security.Cryptography.X509Certificates o
n .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with wi
n81-x64.
System.Security.Cryptography.Encoding 4.0.0-rc2-24018 provides a compile-tim
e reference assembly for System.Security.Cryptography.Encoding on .NETCoreApp,Ve
rsion=v1.0, but there is no run-time assembly compatible with win81-x64.
Microsoft.Win32.Registry 4.0.0-rc2-24018 provides a compile-time reference a
ssembly for Microsoft.Win32.Registry on .NETCoreApp,Version=v1.0, but there is n
o run-time assembly compatible with win81-x64.
System.IO.FileSystem.Watcher 4.0.0-rc2-24018 provides a compile-time referen
ce assembly for System.IO.FileSystem.Watcher on .NETCoreApp,Version=v1.0, but th
ere is no run-time assembly compatible with win81-x64.

System.Globalization.Extensions 4.0.1-rc2-24018 provides a compile-time refe
rence assembly for System.Globalization.Extensions on .NETCoreApp,Version=v1.0,
but there is no run-time assembly compatible with win81-x64.
System.Security.Cryptography.Cng 4.1.0-rc2-24018 provides a compile-time ref
erence assembly for System.Security.Cryptography.Cng on .NETCoreApp,Version=v1.0
, but there is no run-time assembly compatible with win81-x64.
System.Security.Cryptography.Csp 4.0.0-rc2-24018 provides a compile-time ref
erence assembly for System.Security.Cryptography.Csp on .NETCoreApp,Version=v1.0
, but there is no run-time assembly compatible with win81-x64.
System.Diagnostics.Tools 4.0.1-rc2-24018 provides a compile-time reference a
ssembly for System.Diagnostics.Tools on .NETCoreApp,Version=v1.0, but there is n
o run-time assembly compatible with win81-x64.
One or more packages are incompatible with .NETCoreApp,Version=v1.0 (win81-x
64).
NuGet Config files used:
C:\Users\ibrmohammed\Source\Workspaces\SbmAps\Idp\NuGet.Config
C:\Users\ibrmohammed\AppData\Roaming\NuGet\NuGet.Config
Feeds used:
https://www.myget.org/F/aspnet-contrib/api/v2
https://www.myget.org/F/aspnetvnext/api/v2
http://www.myget.org/F/azureadwebstacknightly/
https://api.nuget.org/v3/index.json
https://www.myget.org/F/xunit/api/v3/index.json
https://www.myget.org/F/aspnetcirelease/api/v3/index.json

@davidfowl any thing more that I have to check.to get this resloved


Update the usage of showSaveDialog to use the Promise. ( Electron 9 upgrade PR )

Requirements for Contributing a Bug Fix

Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only fix an existing bug. To contribute other changes, you must use a different template. You can see all templates at https://github.com/atom/.github/tree/master/.github/PULL_REQUEST_TEMPLATE.
The pull request must update the test suite to demonstrate the changed functionality. For guidance, please see https://flight-manual.atom.io/hacking-atom/sections/writing-specs/.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see https://github.com/atom/.github/tree/master/CONTRIBUTING.md#pull-requests.

Identify the Bug

Description of the Change
Identify one usage of Dialog.showSaveDialog and remove the callback utilization since the callback is no more executed.
old doc where the callback is described:
https://github.com/electron/electron/blob/v5.0.13/docs/api/dialog.md#dialogshowsavedialogbrowserwindow-options-callback
new doc where showSaveDialog is promisified
https://github.com/electron/electron/blob/master/docs/api/dialog.md#dialogshowsavedialogbrowserwindow-options
There are those extra usage of showSaveDialog
https://github.com/atom/atom/blob/master/src/application-delegate.js#L274
In this case the this.getCurrentWindow() is remote.getCurrentWindow(), that returns a BrowserWindow.
https://www.electronjs.org/docs/api/remote#remotegetcurrentwindow
The BrowserWindow class does not seem to have a showSaveDialog, i m not sure if it inherits somehow the Dialog methods.
@DeeDeeG  any hint?

Alternate Designs

Possible Drawbacks

Verification Process

Release Notes

The BrowserWindow class does not seem to have a showSaveDialog, i m not sure if it inherits somehow the Dialog methods.
@DeeDeeG any hint?

Hi again @asturur. I believe BrowserWindow gets showSaveDialog() bound on this line:
https://github.com/atom/atom/blob/v1.54.0/src/main-process/atom-window.js#L154

Ok my question then is, do you want to deprecate the callback interface of Atom too? or just fix electron usage?
And if you want to remove callbacks from atom too, doesn't that require a major version bump and a different PR?
Let me know.

do you want to deprecate the callback interface of Atom too? or just fix electron usage?

This is a question for the core Atom maintainers, in my opinion. (Although from past situations, I can say they usually value input from contributors on such questions.)
I personally would lean toward making sure Atom's code still supports/runs the callbacks, if that's possible. So as to not break community packages. But I'm not sure how hard that would be.

doesn't [deprecating the callback interface of Atom] require a major version bump and a different PR?

I'm not sure if Atom wants to follow semver. That would be a question for Atom's official maintainers. Likewise, requiring a different PR would be a question for Atom's official maintainers.
cc @sadick254 @darangi there are some questions about how stable the public Atom API should be while fixing the app for Electron 9. And if there are breaking changes to Atom's API, how exactly to handle that in terms of PRs and Atom version numbers. Please see above, thank you.

If you ask me, you do not want to break the api now.
Is easy enough to make those old callback methods return the promise, and let people chain the callback themselves in the then and still support the callback.
Then deprecate the callback and then remove it, as electron did.

Hey @DeeDeeG @asturur
One of our main goal is to maintain Atom's stability. Which means major changes to the public API would highly be unlikely. We therefore share both your opinions on this.

I personally would lean toward making sure Atom's code still supports/runs the callbacks, if that's possible. So as to not break community packages

If you ask me, you do not want to break the API now

@sadick254 @DeeDeeG @asturur
But at least giving a deprecation notice for the callback method could be of extra added value. If electron (and JS-coding in general) moves to prefer promises over callbacks, it would hint to developers the preferred way for implementation. And would at least move things forward in coding consistency when more (future) API methods will use promises too.
And it would at least create the flexibility in a very far future to drop callback support if for some reason the need would arise.

ok, I understand. Just wanted to make sure that there is no extra burden in maintenance to keep the callbacks. And in general it is logical to stick to the same design patterns as your toolkit :-)


Remove hardcoded audience text for youth events

What?
Events tagged with the audience 14 to 19 year-olds have hardcoded text on the page.

For 14 to 19-year-olds
This activity is for people aged 14 to 19 years old and disabled people aged 14 to 25 years old.

The Content team would like to remove this.
Example: https://wellcomecollection.org/events/ZJ03hhAAACEAciDL

Why?

Information is also included in the body of the event.
Information's placement below InfoBox makes it less visible anyway.

Done when

Events with the 14-19 audience tag no longer shows the additional text below the InfoBox

Confirmed changing section to prevent all hardcoded guidance here: Slack


Logging messages in its raw format

Following up on #31, if I want to collect different raw message strings received by openwechat and display them in terminal, what shall I do?
The purpose of this is that, when I got an attachment, say a .pdf file, I want to see if the file name is anywhere within the message itself. And same for other cases like getting pictures, or voices, etc.
You can use code in README or from #9 as the starting point. THX!

你可以通过访问msg.Content属性来获取当前文件消息相关的信息
下面是消息原始内容实例（图片消息）
{
"MsgId": "8733495435436186388",
"FromUserName": "@07023c3d24b6335fc03d2167bd99738cabe2f77f287c37cc1be180be278ee6d1",
"ToUserName": "@739ad0700033802d4834036bf53c5d151f9c5599a35acb2f16ce5ad1e94ed182",
"MsgType": 3,
"Content": "<?xml version=\"1.0\"?>
<msg>
\t<img aeskey=\"0397f8bea20e2c408f6ef4532d45c72e\" encryver=\"0\" cdnthumbaeskey=\"0397f8bea20e2c408f6ef4532d45c72e\" cdnthumburl=\"30780201000471306f020100020430ff370f02033d120002040f403379020460f588db044a617570696d675f386531326461656238376637366335665f313632363730343039313331355f30306633633363372d366665362d343833372d393232642d613238373963396463663430020401152a010201000400\" cdnthumblength=\"6243\" cdnthumbheight=\"120\" cdnthumbwidth=\"90\" cdnmidheight=\"0\" cdnmidwidth=\"0\" cdnhdheight=\"0\" cdnhdwidth=\"0\" cdnmidimgurl=\"30780201000471306f020100020430ff370f02033d120002040f403379020460f588db044a617570696d675f386531326461656238376637366335665f313632363730343039313331355f30306633633363372d366665362d343833372d393232642d613238373963396463663430020401152a010201000400\" length=\"1\" cdnbigimgurl=\"30780201000471306f020100020430ff370f02033d120002040f403379020460f588db044a617570696d675f386531326461656238376637366335665f313632363730343039313331355f30306633633363372d366665362d343833372d393232642d613238373963396463663430020401152a010201000400\" hdlength=\"64848\" md5=\"76bd10b2da160f869e4cf07e9d236f55\" hevc_mid_size=\"15412\" />
</msg>
",
"Status": 3,
"ImgStatus": 2,
"CreateTime":<PHONE_NUMBER>,
"VoiceLength": 0,
"PlayLength": 0,
"FileName": "",
"FileSize": "",
"MediaId": "",
"Url": "",
"AppMsgType": 0,
"StatusNotifyCode": 0,
"StatusNotifyUserName": "",
"RecommendInfo": {
"UserName": "",
"NickName": "",
"QQNum": 0,
"Province": "",
"City": "",
"Content": "",
"Signature": "",
"Alias": "",
"Scene": 0,
"VerifyFlag": 0,
"AttrStatus": 0,
"Sex": 0,
"Ticket": "",
"OpCode": 0
}
,
"ForwardFlag": 0,
"AppInfo": {
"AppID": "",
"Type": 0
}
,
"HasProductId": 0,
"Ticket": "",
"ImgHeight": 120,
"ImgWidth": 90,
"SubMsgType": 0,
"NewMsgId":<PHONE_NUMBER>436186388,
"OriContent": "",
"EncryFileName": ""
}

Thanks a lot!

Strange, why my msg.Content is in xml format, while yours is in JSON?
Here is my msg.Content after receiving an image:
<?xml version=\"1.0\"?>
<msg>
\t<img aeskey=\"93dc26e94e7764eb58621e7906321570\" encryver=\"0\" cdnthumbaeskey=\"93dc26e94e7764eb58621e7906321570\" cdnthumburl=\"30780201000471306f02010002048b8fde7b02033d096802045d8b2065020460f781ca044a617570696d675f623761333130636266336265663536365f313632363833333335333632395f62346139313765342d366162362d343463622d383432312d3730306362353532376665350204012d0a020201000400\" cdnthumblength=\"7486\" cdnthumbheight=\"107\" cdnthumbwidth=\"120\" cdnmidheight=\"0\" cdnmidwidth=\"0\" cdnhdheight=\"0\" cdnhdwidth=\"0\" cdnmidimgurl=\"30780201000471306f02010002048b8fde7b02033d096802045d8b2065020460f781ca044a617570696d675f623761333130636266336265663536365f313632363833333335333632395f62346139313765342d366162362d343463622d383432312d3730306362353532376665350204012d0a020201000400\" length=\"62022\" md5=\"2d585878ca83673d9852c61b790afd1b\" hevc_mid_size=\"62022\" />
</msg>

你可以通过访问msg.Content属性来获取当前文件消息相关的信息

Hmm, no, that's not the kind of raw format that I am talking about. For e.g., this is,
<?xml version=\"1.0\"?>
<msg>
\t<appmsg appid=\"\" sdkver=\"0\">
\t\t<title>经济学家调查：美国经济增速已见顶 将面临一系列独特风险</title>
\t\t<des>受调查的经济学家们表示，美国经济今年的整体增长速度将达到6.9%，而到2022年将降低到3.2%，到2023年则进一步降低到2.3%。</des>
\t\t<username />
\t\t<action>view</action>
\t\t<type>5</type>

This is a type==5 message, and there are many more different types, like

https://github.com/padlocal/wechaty-puppet-padlocal/issues/76, type 51 & 54
https://github.com/padlocal/wechaty-puppet-padlocal/issues/71, type 3
https://github.com/padlocal/wechaty-puppet-padlocal/issues/58, type 0

etc

Found the source,
https://github.com/eatMoreApple/openwechat/blob/b2178d32a28d61fb195adbc1575d574afbaed49f/parser.go#L108
Would it be possible that you cache this buffer.Bytes() inside msg as Payload or RawPayload please?

The reason behind that is that,
I want to collect every possible raw messages openwechat can received, and use CI/CD automation to automatically generate Go date structure for them.

我觉得不用呀，因为它已经被转换了Message结构体了，再存储一份岂不是冗余的数据了吗，如果您想实现您的需求，再进行一次转换就好了呀

Hmm... the point is that I want to verify if the process of 转换成Message结构体 is solid.
E.g., There are many types, 3, 5, 51, 54 etc, are they all have been converted exactly as they should be?
Basically different types (3, 5, 51, 54 etc) have totally different date structures,  I want to verify if they indeed have been converted properly. I.e., it is hard to believe that different types, different date structures, can all be converted to the same Message结构体 properly.

For e.g., this is straight from msg.Content, not quite being converted properly.
<?xml version=\"1.0\"?>
<msg>
\t<appmsg appid=\"\" sdkver=\"0\">
\t\t<title>经济学家调查：美国经济增速已见顶 将面临一系列独特风险</title>
\t\t<des>受调查的经济学家们表示，美国经济今年的整体增长速度将达到6.9%，而到2022年将降低到3.2%，到2023年则进一步降低到2.3%。</des>
\t\t<username />
\t\t<action>view</action>
\t\t<type>5</type>

Right after login, I'd receive at least two messages:
TS=0724T16:17:03 Msg=收到消息 type="51 (0,0)" content=
TS=0724T16:17:08 Msg=收到消息 type="51 (0,0)" content=

I want to see the raw Payload of the above 2 messages as well.
I tried to make the following simple changes:
$ git diff caller.go
diff --git a/caller.go b/caller.go

index f807d00..f43b3e0 100644
--- a/caller.go
+++ b/caller.go
@@ -3,6 +3,7 @@ package openwechat
 import (
        "bytes"
        "errors"
+       "fmt"
        "net/http"
        "net/url"
        "os"
@@ -195,6 +196,13 @@ func (c *Caller) WebWxSync(request *BaseRequest, response *WebInitResponse, info
                return nil, err
        }
        defer resp.Body.Close()
+
+       var buffer bytes.Buffer
+       if _, err := buffer.ReadFrom(resp.Body); err != nil {
+               return nil, err
+       }
+       fmt.Println("PL: ", string(buffer.Bytes()))
+
        var webWxSyncResponse WebWxSyncResponse
        if err := scanJson(resp, &webWxSyncResponse); err != nil {
                return nil, err

But my code would hang because of that. Verified many times by flipping them on & off.
Don't know why it is that, :(.
I need this.
Please help.

会不会是你上面将Body读完了，然后下面再去读就读取不了了

Ah, it must be then. THX!

I still need such raw-format dumping function badly. @eatmoreapple, please think of a way so that I can get it.
So far, the best way I can think of is to define a global variable, and set it within scanJson after buffer.ReadFrom(resp.Body), then define a new API, GetLastResponseBodyRaw() or something so that I can read from this global variable.
@eatmoreapple, please implement anything so that I can get the raw message strings received from the WX server without any modification. This is for my #64 implementation. Thanks!

Hmm... hold on, let me investigate a fiddler-recording-alike solution first...


start.sh "find_path_up" returns root instead of emitting an error message

In build/start.sh, we do the following logic:
dir_mad=`find_path_up metrics-aggregator-daemon`

if [ "${start_mad}" -gt 0 ] && [ ! -d "${dir_mad}" ]; then
  echo "No directory found for requested project mad"
  exit 1
fi

As it turns out, find_path_up returns the root / if it can't find such a sibling directory.
This makes the  [! -d "${dir_mad}"] check - that is to say, the [not folder-exists /] - always evaluate to false, meaning we'll never fall into any of these 3 if statements.

Including in my next PR.


Move back to one PR template

Description
Move back to one PR template. The two-template thing isn't that clean in the GH interface.
Checklist

[x] Documentation, including doctests
[x] Git history is linear
[x] Commit messages are descriptive
[x] (optional) Git commit messages follow conventional commits
[x] Code is formatted (cargo fmt)
[x] cargo test
[x] Changes are added to the CHANGELOG

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 53.246%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
1166

Relevant Lines:
1351

💛  - Coveralls


unable to load model 'face_graphdef', configuration expects 1 inputs, model provides at most 0

unable to load model 'face_graphdef', configuration expects 1 inputs, model provides at most 0
Triton Information
20.03-py3
container
Steps to reproduce the behavior.
1 download face feature.pb model
2 config
name: "face_graphdef"
platform: "tensorflow_graphdef"
max_batch_size: 4
input [
{
name: "IteratorGetNext"
data_type: TYPE_FP32
format: FORMAT_NHWC
dims: [ 112, 96, 3 ]
}
]
output [
{
name: "l2_normalize"
data_type: TYPE_FP32
dims: [ 128 ]
}
]
3 trtserver --model-repository=/models
error:
E0410 10:20:53.438208 823 model_repository_manager.cc:840] failed to load 'face_graphdef' version 1: Invalid argument: unable to load model 'face_graphdef', configuration expects 1 inputs, model provides at most 0
this error indicate that my PB model or the config has bug?
Expected behavior
successfully loaded 'face_graphdef' version 1

The error indicates that the model does not appear to have any inputs. For a graphdef that means that Triton could not find any placeholder nodes in the graph. Are you able to load this graphdef by using the TF python APIs directly?

The error indicates that the model does not appear to have any inputs. For a graphdef that means that Triton could not find any placeholder nodes in the graph. Are you able to load this graphdef by using the TF python APIs directly?

Thank you for your replying. I have tested on tensorflow python API and c++ API, they did good. In Triton server i just modified the extension format "pb" to "graphdef". Is that right?

find the reason.
tensorflow_backend_tf.cc:856
if (node.op() == "Placeholder") {
only support input node with Placeholder op.
I just convert graphdef to savemodel, it works.


Build fail - check_default failed (branch incorrect)

Hey @stokesriona,
In the repo all my tests passed, only the maintain one failed.
When I check to see the error, it says:
FAIL test/refer.test.ts
  refer
    ✓ happy (280 ms)
    ✓ basic.messages (577 ms)
    ✕ maintain (1075 ms)

  ● refer › maintain

    Failed Checks:

    check_default failed (branch incorrect)

      at runChecks (node_modules/@seneca/maintain/maintain.js:78:15)

However, looking into the seneca-maintain docs, it should't fail, right? As my default branch is named "main" and not "master".
Please, could you help me debug this?

Hi, thanks for following up!
You're right, it shouldn't be failing. Can I ask what number version of @seneca/maintain is in your local package.json file?

"@seneca/maintain": "^0.0.20",

I've pushed the latest version to npm, version 0.0.22 . Please update with npm install -D @seneca/maintain@latest and let me know if the error persists

I just updated to the latest version, yet the error persists.  Please, take a look at my PR. I don't know if I missing something here...
It's strange, because in my local machine, all tests pass(including the maintain one). The error shows up only in the GitHub pipe line. Let me know, if you need more info.


UIImage-Handling the problem of blurry network images

Describe the bug
When using network images, there is no need to specify the resolution, because the code will get the default screen resolution
To Reproduce
let format = UIGraphicsImageRendererFormat()
// format.scale = self.scale <------- delete this line
Expected behavior
The original code will cause the transformed image to be blurry,
self.scale is always 1, when UIImageView.image will be setted

@wangyuchaogeek can you please provide some kind of example. I'm not sure how reusing the image scale breaks the transformation.


Regression test for the size and gas cost of the host_function_metrics contract (Issue #2049)

Closes #2049
There are only two issues here:

These tests cannot possibly be a comprehensive benchmark for other contracts; and
For some reason, the second test outputs garbage to the terminal (if it fails or cargo test has been passed -- --show-output).

The problem @dwerner and I were have previously is that refactoring crates creates regressions in gas costs in the various test contracts.  I have the same concern regarding the hashing-crate refactor.
I'm not sure how this solves that issue, but this is desirable anyway...

@mpapierski could you take a look?

bors r+


Sidebar Title

The sidebar title is placed weirdly and also missing the icon

Don't assign it to me just wanted to point out
This can be a good first issue for newcomers :)

Thanks for pointing it out


Add logo to README

Adds logo.
Changes
How I tested this
Notes
Checklist

[ ] PR has an informative and human-readable title (this will be pulled into the release notes)
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future TODOs are captured in comments
[ ] Project documentation has been updated if adding/changing functionality.

Closing as we already did this


The matplotlib drawing window cannot display images and automatically closed at a very fast speed.

For example, the following code
import gdsfactory as gf
@gf.cell
def mzi_with_bend(radius: float = 10):
c = gf.Component()
mzi = c << gf.components.mzi()  # equivalent to mzi = c.add_ref(gf.components.mzi())
bend = c << gf.components.bend_circular(
radius=radius
)  # equivalent to bend = c.add_ref(gf.components.bend_circular())
bend.connect("o1", mzi.ports["o2"])
return c
c = mzi_with_bend(radius=20)
c.plot()
c.show()
There will be corresponding structure output in the klayout software, but the following images cannot be displayed in the matplotlib drawing window.

My Python interpreter version：python 3.9.13
gdsfactory version:   6.2.6
matplotlib version：3.5.2
Operating system：Windows11
IDE: Pycharm

Hi @HWOde,
did you try adding a plt.show() line after c.plot()? That is what I do if I want the window to stay open.

Bravo, it works!😊@ SkandanC

@SkandanC  😊 Thank you so much for your kind help and have a good day！


docs: add Changelog for Ireland release

Signed-off-by: Jim White<EMAIL_ADDRESS>PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/go-mod-messaging/blob/master/.github/Contributing.md.
What is the current behavior?

Issue Number:
What is the new behavior?
Added CHANGELOG.md for Ireland
Does this PR introduce a breaking change?

[ ] Yes
[x] No

New Imports

[ ] Yes
[x] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
Other information

Codecov Report

Merging #110 (8594d00) into master (19fd5df) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #110   +/-   ##
=======================================
  Coverage   81.31%   81.31%
=======================================
  Files          14       14
  Lines         455      455
=======================================
  Hits          370      370
  Misses         65       65
  Partials       20       20

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 19fd5df...8594d00. Read the comment docs.


ci(mergify): configure mergify

:tada: This issue has been resolved in version 2.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Able to upload 290+ files adding this lockType

Related to #999

I'll close this issue because I'm not so happy to have a explicit lock when we already found other strange behavior
https://github.com/trustification/trustify/issues/1036


Add the new slides by @matsumana

Added a new article with slides: 'Spring BootユーザのためのArmeria入門'.
Updated the <Article /> component to allow specifying more than one type.

Updated some articles to take advantage of this feature.

Updated the <Article /> component to allow specifying HTML in a description.

@matsumana Would you mind providing the description of your slides/post like this ? :bow:

Thank you!


[BUG] Keep telling me "authentication required for account. (421)" in unRAID docker

Describe the bug
Environment: unRAID docker
I installed icloud-docker and updated the password during installation process. I created config.yaml file under /config and the /icloud folder was created and accessible. Mapping is fine per unRAID.
I also used the following command to log in with password and 6-digt 2FA code filled in :
docker exec -it icloud /bin/sh -c "icloud --username=XXX --region=china --session-directory=/config/session_data"
I never successfully started the service to sync.
To Reproduce
However, restarting the cloud docker in unRAID, it kept telling me this error in log file:
2024-12-02 14:10:54,580 :: INFO :: root :: sync.py :: 82 :: Syncing drive... 2024-12-02 14:10:55,087 :: ERROR :: icloudpy.base :: base.py :: 186 :: Authentication required for Account. (421)
No matter how repeatedly I have been using the command mentioned above (no error message received), still I got the error messages and icloud is unable to sync.
Expected behavior
Could you please help let me know the step to go through "authentication required for account" message. Thanks
Configuration
config.yaml file as follows:
app:
  logger:
    level: "info"
    filename: "/config/icloud.log"
  credentials:
    username: "XXX"
  retry_login_interval: 600
  root: "/icloud"
  region: "china"
drive:
  destination: "drive"
  remove_obsolete: false
  sync_interval: 300
  filters:
    folders:
      - "Documents"
    file_extensions:
      # File extensions to be included
      - "pdf"
      - "pptx"
      - "xlsx"
      - "docx"

Yeah, authentication is broken. icloud-docker is based on mandarons/icloudpy and it looks like that's a downstream problem from it


.isNewSession is not a function

We have code that looks like:
  window.amplitude.getInstance().onInit(() => {
    const isNewSession = window.amplitude.getInstance().isNewSession();
  });

and we intermittently get errors like:
amplitude.js?091f:172 Uncaught TypeError: window.amplitude.getInstance(...).isNewSession is not a function
    at eval (amplitude.js?091f:172)
    at Re.onInit (amplitude-5.6.0-min.gz.js:1)
    at Re.runQueuedFunctions (amplitude-5.6.0-min.gz.js:1)
    at Fe.runQueuedFunctions (amplitude-5.6.0-min.gz.js:1)
    at amplitude-5.6.0-min.gz.js:1
    at amplitude-5.6.0-min.gz.js:1
    at amplitude-5.6.0-min.gz.js:1

Any help would be greatly appreciated.
EDIT: It appears to be caused by the race condition between using the temporary window.amplitude object that is put on the window in the script tags, and the object that gets loaded once the JS is available.
My question now is: why is onInit being called before the JS is loaded?

Here is a proposed solution: https://github.com/amplitude/Amplitude-JavaScript/pull/259
window.amplitude would continue to be stale by the time the function is invoked, but the fully initialized amplitude instance would be passed to the callback. There wasn't an immediately obvious way to cleanly invoke the callbacks after the module finished loading altogether.
Would the fourth paramater to the the .init function work for what you are trying to do? It already works this way and receives an amplitude instance.
amplitude.getInstance().init('APIKEY', null, {}, (amplitude) => {
   amplitude.isNewSession();
});

@blazzy that solution would be great.
We could pass the callback to the init function, but i'd prefer not to use that since our init is in one of our HTML script tags.

Good to hear. This will likely be released tomorrow!


Fix for #184

Description
Fix for issue #184
Changes

Added test cases to catch the issue.
Allowed passing of zero as min or max value.
If either min or max value is null or coerced to NaN then throw an error.

@thetutlage My code is okay but the build fails due to timeout. The test cases passed for test:node and test:karma but test:qunit requires saucelabs credentials and reaches the timeout.
Related logs:
><EMAIL_ADDRESS>test:qunit /home/travis/build/poppinss/indicative
> node bin/qunit
creating app bundle
started app server on http://localhost:3000
pass SAUCE_USERNAME & SAUCE_ACCESS_KEY to run tests on saucelabs
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated


Add e2e tests for aws-ebs-csi-driver component

Currently there are no e2e tests which test the functionality of aws-ebs-csi-driver component especially dynamic provisioning, volume resizing.
Adding e2e tests with a daily clean up job to delete the created resources would help to catching any errors that might creep up when the component or AWS platform  is updated

Duplicate of #870 ? :wink:

This is to take care of the concerns mentioned in https://github.com/kinvolk/lokomotive/pull/1271#pullrequestreview-555428559


FileStorage.mode attribute should be rb+

When receiving files, werkzeug.datastructures.FileStorage is used. The underlying stream is determined by the default stream factory.
I assume that for most people (if not all?), tempfile.SpooledTemporaryFile will exists, so the following line of code will be executed.
Setting the mode to wb+, thus using an io.BytesIO instance underneath.
When accessing the mode attribute from werkzeug.datastructures.FileStorage, the one from tempfile.SpooledTemporaryFile will be used, and as there is no mode for io.BytesIO, the one set in the constructor will be used, resulting in a write-only mode being returned.
To my knowledge, FileStorage is only returned to read files, so the mode exposed to clients should be read-only.
You can reproduce the bug by checking filestorage.mode while executing this test case.
The impact I see is that pandas seems to rely on mode to determine if a file is readable or not. Changing it to "rb+" instead of "wb+" in the stream factory solves the issue (and avoid sending misleading information to client).
Environment:

Python version: 3.8.6 (Windows 10, 64 bits python)
Werkzeug version: 1.0.1

I guess the distinction that w+ means truncate and r+ means don't isn't relevant when opening these tempfiles, so changing it seems fine.
That said, if Pandas isn't recognizing + as meaning the file is open for reading (and writing), then that's a bug in Pandas. You should report that to them.

It looks like you never reported this issue to Pandas. You need to report it to them as well, they should be recognizing that wb+ allows reading.

It looks like you never reported this issue to Pandas. You need to report it to them as well, they should be recognizing that wb+ allows reading.