LR <IP_ADDRESS> installs executable files with the wrong mode

Example with private info censored out:

$ ls -la /usr/local/bin/example-rock-file
-------r-x 1 root root  1376 2012-02-07 04:07 /usr/local/bin/example-rock-file

$ sudo strace -ff luarocks make ./rockspec/example-rock-scm-1.rockspec |& grep /usr/local/bin/example-rock-file
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|05, st_size=729, ...}) = 0
unlink("/usr/local/bin/example-rock-file") = 0
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
open("/usr/local/bin/example-rock-file", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|0644, st_size=729, ...}) = 0
chmod("/usr/local/bin/example-rock-file", 05) = 0

Note the last line.
Please tell me if you need exact files to reproduce (works for any rock for me).
Rockspec is looking something like this:

package = "example-rock"
version = "scm-1"
source = {
   url = "" -- Can be built with luarocks make only
}
description = {
   summary = "example-rock",
   homepage = "http://example.com",
   license = "MIT",
   maintainer = "Alexander Gladysh "
}
supported_platforms = {
   "unix"
}
dependencies = {
  "lua >= 5.1",
}
build = {
  type = "none",
  install = {
    bin = {
      "bin/example-rock-file"
    }
  }
}

I'm having a hard time to reproduce this. My current suspicion is that
the problem might have something to do with your umask settings.
Please, try changing "chmod +x" to "chmod 0755" in
luarocks/fs/unix.lua and see if that helps.
On Mon, Feb 6, 2012 at 10:45 PM, Alexander Gladysh
<EMAIL_ADDRESS>wrote:

Example with private info censored out:

$ ls -la /usr/local/bin/example-rock-file
-------r-x 1 root root  1376 2012-02-07 04:07 /usr/local/bin/example-rock-file

$ sudo strace -ff luarocks make ./rockspec/example-rock-scm-1.rockspec |& grep /usr/local/bin/example-rock-file
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|05, st_size=729, ...}) = 0
unlink("/usr/local/bin/example-rock-file") = 0
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
open("/usr/local/bin/example-rock-file", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|0644, st_size=729, ...}) = 0
chmod("/usr/local/bin/example-rock-file", 05) = 0

Note the last line.
Please tell me if you need exact files to reproduce (works for any rock for me).
Rockspec is looking something like this:

package = "example-rock"
version = "scm-1"
source = {
  url = "" -- Can be built with luarocks make only
}
description = {
  summary = "example-rock",
  homepage = "http://example.com",
  license = "MIT",
  maintainer = "Alexander Gladysh "
}
supported_platforms = {
  "unix"
}
dependencies = {
 "lua >= 5.1",
}
build = {
 type = "none",
 install = {
   bin = {
     "bin/example-rock-file"
   }
 }
}

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55

Will try and get back to you ASAP.
However, we can reproduce this without a problem on two independently configured developer Ubuntu boxes.
What is your OS? (Will post details on ours as soon as I'll get to my computer.)
10.02.2012, в 21:03, Hisham<EMAIL_ADDRESS>написал(а):

I'm having a hard time to reproduce this. My current suspicion is that
the problem might have something to do with your umask settings.
Please, try changing "chmod +x" to "chmod 0755" in
luarocks/fs/unix.lua and see if that helps.
On Mon, Feb 6, 2012 at 10:45 PM, Alexander Gladysh
<EMAIL_ADDRESS>wrote:

Example with private info censored out:

$ ls -la /usr/local/bin/example-rock-file
-------r-x 1 root root  1376 2012-02-07 04:07 /usr/local/bin/example-rock-file

$ sudo strace -ff luarocks make ./rockspec/example-rock-scm-1.rockspec |& grep /usr/local/bin/example-rock-file
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|05, st_size=729, ...}) = 0
unlink("/usr/local/bin/example-rock-file") = 0
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
open("/usr/local/bin/example-rock-file", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|0644, st_size=729, ...}) = 0
chmod("/usr/local/bin/example-rock-file", 05) = 0

Note the last line.
Please tell me if you need exact files to reproduce (works for any rock for me).
Rockspec is looking something like this:

package = "example-rock"
version = "scm-1"
source = {
  url = "" -- Can be built with luarocks make only
}
description = {
  summary = "example-rock",
  homepage = "http://example.com",
  license = "MIT",
  maintainer = "Alexander Gladysh "
}
supported_platforms = {
  "unix"
}
dependencies = {
 "lua >= 5.1",
}
build = {
 type = "none",
 install = {
   bin = {
     "bin/example-rock-file"
   }
 }
}

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55#issuecomment-3909600

Will try and get back to you ASAP.

Great.

However, we can reproduce this without a problem on two independently configured developer Ubuntu
boxes.

Is the luaposix rock installed in those boxes?

What is your OS? (Will post details on ours as soon as I'll get to my computer.)

I'm running GoboLinux here (essentially, everything is built from source, but packages are pretty vanilla).

On Fri, Feb 10, 2012 at 21:35, Hisham Muhammad
<EMAIL_ADDRESS>wrote:

Will try and get back to you ASAP.

Great.

However, we can reproduce this without a problem on two independently configured developer Ubuntu
boxes.

Is the luaposix rock installed in those boxes?

$ sudo luarocks list | grep -A3 posix
luaposix
   5.1.15-20111010 (installed) - /usr/local/lib/luarocks/rocks

luasec

What is your OS? (Will post details on ours as soon as I'll get to my computer.)

$ uname -a
Linux ubuntu 2.6.35-30-generic #59-Ubuntu SMP Tue Aug 30 15:58:00 UTC
2011 i686 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 10.10
Release:	10.10
Codename:	maverick

That is one, no access to other ATM, if necessary, will get info as well.

I'm running GoboLinux here (essentially, everything is built from source, but packages are pretty vanilla).

If you need a shell on Ubuntu box, give me public key (in private
mail), I'll arrange it.

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55#issuecomment-3910378

On Fri, Feb 10, 2012 at 21:03, Hisham Muhammad
<EMAIL_ADDRESS>wrote:

I'm having a hard time to reproduce this. My current suspicion is that
the problem might have something to do with your umask settings.
Please, try changing "chmod +x" to "chmod 0755" in
luarocks/fs/unix.lua and see if that helps.

No change at all.
Alexander.

On Mon, Feb 6, 2012 at 10:45 PM, Alexander Gladysh
<EMAIL_ADDRESS>wrote:

Example with private info censored out:

$ ls -la /usr/local/bin/example-rock-file
-------r-x 1 root root  1376 2012-02-07 04:07 /usr/local/bin/example-rock-file

$ sudo strace -ff luarocks make ./rockspec/example-rock-scm-1.rockspec |& grep /usr/local/bin/example-rock-file
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|05, st_size=729, ...}) = 0
unlink("/usr/local/bin/example-rock-file") = 0
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/example-rock-file", 0xbf8e8880) = -1 ENOENT (No such file or directory)
open("/usr/local/bin/example-rock-file", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5
stat64("/usr/local/bin/example-rock-file", {st_mode=S_IFREG|0644, st_size=729, ...}) = 0
chmod("/usr/local/bin/example-rock-file", 05) = 0

Note the last line.
Please tell me if you need exact files to reproduce (works for any rock for me).
Rockspec is looking something like this:

package = "example-rock"
version = "scm-1"
source = {
  url = "" -- Can be built with luarocks make only
}
description = {
  summary = "example-rock",
  homepage = "http://example.com",
  license = "MIT",
  maintainer = "Alexander Gladysh "
}
supported_platforms = {
  "unix"
}
dependencies = {
 "lua >= 5.1",
}
build = {
 type = "none",
 install = {
   bin = {
     "bin/example-rock-file"
   }
 }
}

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55#issuecomment-3909600

Removing luaposix fixes the issue:

$ ls -la /usr/local/bin/example-rock-file
-rwxr-xr-x 1 root root 312 2012-02-10 21:50 /usr/local/bin/example-rock-file

I see that we have a custom luaposix rock installed (on both machines). I will check if that is the issue and get back to you.

No, the problem persists if I install stock luaposix from the main LR tree.

Anything different in your umask settings? Mine returns this:

$ umask
022

$ umask
0022

# umask
0022

Looks the same.
On Fri, Feb 10, 2012 at 21:56, Hisham Muhammad
<EMAIL_ADDRESS>wrote:

Anything different in your umask settings? Mine returns this:

$ umask
022

Reply to this email directly or view it on GitHub:
https://github.com/keplerproject/luarocks/issues/55#issuecomment-3910856

Oops, accidentally closed it.
Anyway, I just managed to reproduce it here. A fix should come shortly.

Great! Thanks!

Looks like a bug in luaposix, after all.

$ touch file
$ chmod 0777 file
$ ls -l file
-rwxrwxrwx 1 hisham users 0 Feb 10 17:32 file
$ chmod u=rwx,g=rx,o=rx file
$ ls -l file
-rwxr-xr-x 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ lua -e "require'posix';posix.chmod('file','u=rwx,g=rx,o=rx')"
$ ls -l file
-------r-x 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ chmod u=rwx,g+rx,o+rx file
$ ls -l file
-rwxrwxrwx 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ lua -e "require'posix';posix.chmod('file','u=rwx,g+rx,o+rx')"
$ ls -l file
-rwxr-xr-x 1 hisham users 0 Feb 10 17:32 file

As you can see, the behavior of its argument is not consistent with the chmod command-line tool. :(
I'll work around it in LuaRocks and submit an issue to Reuben.

Hisham, thank you again for the help!

Just found this one little nugget on machine with <IP_ADDRESS>
-rw------- 1 root root 532 2012-02-21 00:26
/usr/local/lib/luarocks/rocks/example_rock/scm-1/example_rock-scm-1.rockspec

Assuming this is the same bug.


NGL 2.2.2 doesn't show bond

Hi
Please see this issue: https://github.com/nglviewer/nglview/issues/1008#issuecomment-1868855451
I am able to reproduce with NGL 2.2.2 too

File is here (need to change .txt to .cif): https://github.com/nglviewer/nglview/files/13765118/last_molecule_r_0-pos-1.txt

The core cif file parsing functions expects the field atom_site_type_symbol to properly infer the element. This cif file does not have it: it only contains the atom_site_label.
It seems that, in this case, we could default to infer element based on the later, in case atom_site_type_symbol is missing.

hi team,
I noted that the browser console warns with 'more than 500 atoms...', it's come from this code.
https://github.com/nglviewer/ngl/blob/master/src/structure/structure-utils.ts#L606-L607
it will work well for me when I change the check limit to 99999. can we have a bigger count limit or the count limit can be a configured parameter?

@jump2cn - That code is inferring bonds between atoms in the same residue, and the 500 is there to avoid an explosion in complexity - I guess it's kind of an arbitrary number but 99999 seems a little high - your file has ~1500 atoms? We could set it to 2500.
I was trying to find an example where it would behave more poorly - it's doing a nearest neighbour search using a kdtree then for each pair looking up to see if they would reasonably be bonded. In your case where there's no disorder that nearest neighbour search isn't going to be a problem even if every atom is queries, most will return only a few neighbours. For something like an NMR structure with 20 models of a large ligand all overlaid I guess it could get expensive, but I couldn't find an example quickly where it was a problem.

How about just make this threshold configurable and still use 500 as the default value, so that the user can decide the right value by theirselve.

Or can I specific bonds in the data file before feeding it to nglviewer, so that it's up to user to decide instead of having nglviewer to guess by distance?


added Douglas County, OR, USA

Fixes #1951

1 week to order data and get it on the map, not bad for snail mail! Thank you :)

On Mar 10, 2017, at 19:52, Stephen K Hess<EMAIL_ADDRESS>wrote:
Merged #2666.
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Documentation is missing

On the website it says the generated documentation is included in the sourceforge downloads page, but all the new releases don't include it. It'd be nice to be able to read the docs without taking the time to generate them.

Hi Matthew,
The docs are not very useful right now. There is the file UPnP_Programming_Guide.pdf which is from version 1.2 times but it is not included in the tar ball.
I have just committed a fix that makes it at least possible to generate the docs with make pdf.
There is a lot of doxygen work to do in order to make the automatically generated documentation of any use.
Regards,
Marcelo.

Hi what is the issue with doxygen specifically? I was able to generate it just fine the last time I worked on pupnp so it shouldn't be too hard to add?

One issue I have fixed last week was that make pdf was broken.
The other issue I should fix by the end of this week and has to do with the automatic files (templates) that do not get documented. I have it almost working.
Other than that, I would like the docs to be readable and usefull, more on the lines of README.md, even if we copy a lot of its content. Maybe put a \mainfile in upnp.h or some other file and go from there. I believe it would be better some file other than upnp.h so as not to make this file big, since it is the one included externally.
Anyway, the changes I am about to commit do not touch any file currently under git, so if someone wants to make changes do the docs, please feel free to do it.
Best regards,
Marcelo.

I would like to integrate pupnp into an application, but without any documentation, it's hard to start.

At least the README should be edited saying the current doc (in the tarball in the docs/ folder) is outdated.

make docs, make pdf and make html in docs all work for me.


unable to upload binary files

http://localhost:9000><EMAIL_ADDRESS>Syntax error near "image@~/Pu"

Sending binary data isn't supported currently but will be added in the future. See #75.


Compatible with nacos grouping via group

What is the purpose of the change
Compatible with nacos grouping via group
see #8317
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #8320 (3b52085) into 3.0 (1abc66a) will decrease coverage by 0.19%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##                3.0    #8320      +/-   ##
============================================
- Coverage     63.93%   63.73%   -0.20%
+ Complexity      311      310       -1
============================================
  Files          1078     1078
  Lines         45728    45683      -45
  Branches       6862     6829      -33
============================================
- Hits          29235    29118     -117
- Misses        13237    13296      +59
- Partials       3256     3269      +13

Impacted Files
Coverage Δ

...apache/dubbo/common/constants/CommonConstants.java
100.00% <ø> (ø)

...o/registry/nacos/util/NacosNamingServiceUtils.java
0.00% <0.00%> (ø)

...ng/transport/dispatcher/all/AllChannelHandler.java
62.06% <0.00%> (-20.69%)
:arrow_down:

...ng/transport/dispatcher/WrappedChannelHandler.java
47.82% <0.00%> (-15.22%)
:arrow_down:

...dubbo/common/status/support/LoadStatusChecker.java
50.00% <0.00%> (-11.54%)
:arrow_down:

...in/java/org/apache/dubbo/common/utils/JVMUtil.java
81.13% <0.00%> (-11.33%)
:arrow_down:

.../apache/dubbo/remoting/transport/AbstractPeer.java
58.69% <0.00%> (-10.87%)
:arrow_down:

...mmon/threadpool/support/fixed/FixedThreadPool.java
80.00% <0.00%> (-7.50%)
:arrow_down:

.../remoting/transport/netty4/NettyClientHandler.java
57.62% <0.00%> (-6.78%)
:arrow_down:

...moting/transport/netty4/NettyEventLoopFactory.java
30.00% <0.00%> (-6.37%)
:arrow_down:

... and 42 more

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 1abc66a...3b52085. Read the comment docs.


Worklogadd doesn't work

The #35 lists my setup. Once I made jira-cmd work, I created the issue from the Web GUI.
It's called CS-519.
Next I do:
jira worklogadd CS-519 3h something
I don't see these changes reflected in the Web GUI. It seems like nothing has been changed. Output on the console:
wkoszek|19:07:07|0|/Users/wkoszek/.jira$ jira worklogadd CS-519 3h something
Worklog to issue [CS-519] was added!.

If you are still facing the issue please feel free to reopen the issue, and we'll solve it together : ) .

@palashkulsh I have moved to another position where we don't use JIRA anymore, so I don't have a way to test it. Thanks for replying.

no problemo @wkoszek  .


bower project changing license

Ran into an issue recently with a project jqgrid, which recently changed from a free license to a proprietary one (dual licensed with a non-commercial CC license).
What is the best way to handle this situation?  Should I just skip bower altogether and use the latest liberally licensed version?  Should I create a separate fork pinned to the last free version?

I'd just choose the package using a git sha or tag that presents the licence that you want.

eg:
"c3": "c76c89273b11665d9ddaf73dd6231c5839122328"


Wrong output value of TPUVMs when the cluster have the string tpu in its name

Hi,
I noticed that when I run python3 xpk.py cluster describe --cluster <MYCLUSTER> the number that returns in the message can be wrong if you name your cluster with the string tpu in its name (e.g., my-tpu-cluster). The command  kubectl get node --no-headers=true | grep '\-tpu\-' | wc -l would fetch even the default-node and consider it a TPU node and show a wrong value in the output.
Here is the line in xpy.py I am mentioning https://github.com/google/xpk/blob/main/xpk.py#L1186
A workaround for that could be instead kubectl get node --no-headers=true --selector='cloud.google.com/gke-tpu-accelerator' | wc -l

Thank you William for the bug and fix! Will get on this shortly. :)


Bandwidth on TPU v3 > 900 GB/s

I've testing the performance of EmbeddingTPU on GCP TPU v3-8. I found that the computed memory access
bandwidth is beyond > 900 GB/s when using one core (900 GB/s is the theoretical upper bound). I think this may be
a tensorflow bug. The test code is developed in Python interface.
Here is the code TGTBT.py and the tf_env.txt (file is too big to put here, collected using tf_env_collect.sh).
https://github.com/shz0116/testTF/blob/master/TGTBT.py
https://github.com/shz0116/testTF/blob/master/tf_env.txt
The run command and output is listed at the top of TGTBT.py file. It's pretty simple.
~$ python3 -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"
v1.12.1-34769-gfd2d4cdb70 2.3.0-dev20200620
Describe the current behavior
We see the computed memory bandwidth for one TPU v3 core is > 900 GB/s.
Describe the expected behavior
We expect the bandwidth number is below 900 GB/s.
Standalone code to reproduce the issue
See above.
Update: I found that if I add a statement res.numpy() into the timer, the performance will change from too good (> 900 GB/s) to too bad (1.4 GB/s).

Hi @shz0116, when you say bandwidth is beyond > 900 GB/s, what is the number you calculated? Trying to understand how much larger than 900. Additionally, can you explain how you did this calculation? I see in your script that your calculation for total_bytes depends on command line arguments, and I'm wondering what those numbers were. Additionally can you explain what em and nnz are?

This is for table lookup. Suppose you have a 2D table or matrix, T[features=1000000, em=128] datatype=float32.
Each time (or call batch), we search nnz rows and compute the sum across the columns. The row id is generated by random.
Now we have a sum vector with size [em=128].  Here we repeat the search 65536 times.
So, finally we have a results matrix R[batch=65536, em=128].
During this process, we read from the matrix (or memory) total_bytes data. So the memory bandwidth is total_bytes/Time.
It should be less than theoretical memory bandwidth. By the way, TPU have cache or not like CPU cache ?
Hope this helps. Just let me know if you have any question.

What was the result of the calculation you did? You mentioned it was larger than 900, But what was the actual number?

1683.631 GB/s
The line 10 in file https://github.com/shz0116/testTF/blob/master/TGTBT.py.

Can you point to where you found the upper bound to be 900 GB/s ?

https://cacm.acm.org/magazines/2020/7/245702-a-domain-specific-supercomputer-for-training-deep-neural-networks/fulltext
Did you find anything wrong with my code ?

Thanks for sharing that link. Although I couldn't find the 900GB/s noted there specifically. I don't think there's any bug here since it's not possible for the bandwidth to be higher than the maximum bandwidth. It seems that if your calculation is correct than the upper limit for bandwidth is > 900 GB/s.

Look at "Table 3. Key processor features." Row : Memory GBs/Chip.
I think we are lacking a reasonable explanation why BW > 900 GB/s the theoretical peak if not a bug.
Do you know whether TPUEMbedding implementation using multiple threading or other parallel data access ?

I think in this case it would be worth contacting the authors of that link you provided to understand how they measured the 900GB/s. It doesn't make sense for the BW to be higher than the limit, so either the limit is greater than 900 or your calculation is incorrect. Either way, I think the best next step is to contact the authors to better understand how they got the 900GB/s number.


Maze generator example

This is a maze generator example that compiles just fine under XC-BASIC. ;)

This is super cool! :-)

Thanks. :)
Next step is charset modification. I don't fully understand it yet, but I try.
I sent you a mail last night with an earlier version of the code. Did it land in the spam folder?


feat(ptoken): <- remove all ERC777 hooks from that

...per title.
NOTE: Hook calls have been commented out in the contract in question, though the hook logic remains.
NOTE: Test w/r/t the tokensReceivedHook have been skipped for now.

I've done one better because we need a more robust test for the upgrade compatibility since it's so critical.
So if you review the latest addition you'll see that test.
Basically we use a child process to clone the whole repo to temp dir, checkout master there, flatten the pToken.sol contract, copy that contract into the main repo's ./contracts dir, then finally use ethers' upgrades.validateUpgrade fxn to check we've not broken the storage compatibility.
Having this test here (and runnable in the CI which I've also added) gives me much confidence going forward since we're likely to be editing this contract more in future.


testing: Use low-reputation billing account

This change swaps out the "standard" billing account for a "low reputation" billing account. This is intended to see if our automated testing process can surface more accurate end-to-end error conditions faced by folks using this blueprint in a wider range of circumstances.
Considerations for merge include:

Are the error messages sufficiently distinct from other errors we are likely to surface in testing that we can simply switch, rather than establish a "billing account matrix" and test both ways?

Lint error is because of temporary change to variable defaults.

@grayside did you want this one merged, and #79 closed unmerged?

Yes, this is one I want merged. #79 is for additional experimentation but I don't have a current next experiment so we can close.

/gcbrun

Glad I merged this second in the queue. There's some interesting errors after merging #58
First error:
suffix-example-apply: Error: "404" is not less than or equal to "299"

DefineApply from tests runs during apply. This came up because the placeholder didn't successfully deploy. We may want to add placeholder job polling like we do on client deploy job polling.
On retry:
suffix-example-apply: Error: Error creating service account: googleapi: Error 429: A quota has been reached for project number NNN: Service accounts created per minute per project.

This is temporal?

/gcbrun

/gcbrun

/gcbrun

Cause of build errors in #84
API issue looks temporal, not re-created.