Updated settings

Updated settings for debugging and more variables to overcome bugs

Hi @UmarGit! Thank you for continuing to troubleshoot and debug environmental variables in settings.py.  I noticed that the OpterationalError is still present and not quite resolved just yet.  I look forward to seeing more progress soon. :)

When I Google: ‘heroku ssl django operationalerror pgbouncer’, it turns up a known issue described in an on the official Heroku GitHub repo titled: “django.db.utils.OperationalError: server does not support SSL, but SSL was required #118”.
That is our issue precisely. A number of other users chimed in with a solution that seems to resolve the issue for all of them. The solution is to add:
del DATABASES['default']['OPTIONS']['sslmode']

after:
django_heroku.settings(locals())

When I make that change, I didn't bother committing the change or pushing to Heroku because my local Django dev server exits with this traceback:
File "/home/gnull/dev/projects/python/2018-and-2020/tarot_juicer/tarot_juicer/settings.py", line 150, in <module>
    del DATABASES['default']['OPTIONS']['sslmode']
KeyError: 'OPTIONS'

So this is probably not the solution we need.

Hey @enoren5
Today, I was very curious and after brain-storming, I see you had advised me to delete the sslmode key from database dictionary, but as we are trying to do that, we fail, because the problem is in the library, Like as:
django_heroku.settings(locals())

We need to delete the sslmode key after that line, but why ?

Because it is altering our assigned DATABASE_URL or modifying it, but How can I prove it ?

I directly jumped into the django_heroku library and found there, when we call this as django_heroku.settings(locals()) it checks for a env variable named DATABASE_URL and alter the DATABASE_URL as dj_database_url.config(conn_max_age=MAX_CONN_AGE, ssl_require=True)

Which is in our case, causing our server to throw OperationalError at /
server does not support SSL, but SSL was required

So after further, reading the library, I found that we can disable this behaviour of django_heroku by providing a flag as:

#databases=False
django_heroku.settings(locals(), databases=False)

So after that this behavior will be disabled and we can have our DATABASE value un-modified.

For Reference of the library go to your local tarot_juicer repo then venv/lib/python3.8/site-packages/django_heroku/core.py
in that file, you will get more clear idea, of what I am trying to explain

That's all I had done
Best Regards
Umar Ahmed

At line 149 in settings.py I changed: django_heroku.settings(locals()) to django_heroku.settings(locals(), databases=False). You can see that here: https://github.com/enoren5/tarot_juicer/blob/master/tarot_juicer/settings.py
I committed the change, pushed to Heroku, and rebuilt the project using the build pack. The SSL error appears to be gone. Hooray! But now there is a missing table trace-back:
ProgrammingError at /
column accounts_authtoggle.enable_protection does not exist
LINE 1: SELECT "accounts_authtoggle"."id", "accounts_authtoggle"."en...

You can see it here: https://tarot-juicer-next-iter.herokuapp.com/
I've seen this error before. It usually indicates that the the db needs to be migrated/makemigrations. When I ran those commands, I got this:

(venv) $ heroku run python manage.py makemigrations
›   Warning: heroku update available from 7.47.7 to 7.47.12.
Running python manage.py makemigrations on ⬢ tarot-juicer-next-iter... up, run.1528 (Hobby)
postgres://jckmeibmxypuvn:11033b956dd9cc6011e8efb7d23d56bb277bef7e9634a31ae0f0b304f34e9667@ec2-3-231-241-17.compute-1.amazonaws.com:5432/d9eds0cfpna1li
{'default': {'NAME': 'd9eds0cfpna1li', 'USER': 'jckmeibmxypuvn', 'PASSWORD': '11033b956dd9cc6011e8efb7d23d56bb277bef7e9634a31ae0f0b304f34e9667', 'HOST': 'ec2-3-231-241-17.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}}
No changes detected
(venv) $ heroku run python manage.py migrate
›   Warning: heroku update available from 7.47.7 to 7.47.12.
Running python manage.py migrate on ⬢ tarot-juicer-next-iter... up, run.2673 (Hobby)
postgres://jckmeibmxypuvn:11033b956dd9cc6011e8efb7d23d56bb277bef7e9634a31ae0f0b304f34e9667@ec2-3-231-241-17.compute-1.amazonaws.com:5432/d9eds0cfpna1li
{'default': {'NAME': 'd9eds0cfpna1li', 'USER': 'jckmeibmxypuvn', 'PASSWORD': '11033b956dd9cc6011e8efb7d23d56bb277bef7e9634a31ae0f0b304f34e9667', 'HOST': 'ec2-3-231-241-17.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}}
Operations to perform:
Apply all migrations: accounts, admin, auth, contenttypes, essays, generators, landings, sessions
Running migrations:
No migrations to apply.

Notice that the DATABASES environment variable (dictionary) is being printed? It looks like Heroku is using the postgresdb successfully. Woohooo!
I'm just not sure what I am doing wrong to overcome the migrations/migrate error now.  Just to double check your advice from prior contracts, I even ran: $ heroku run python manage.py makemigrations accounts (notice that I specifically indicated the accounts app) which still returned: No changes detected in app 'accounts'. Any ideas what to try next?

First revert the migration as the name of auto toggle is changed:

$ python manage.py migrate accounts zero

Second migrate it with new name:

$ python manage.py migrate accounts

Resolves #69


Use tabs for dataproc docs

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder/9373/
Test FAILed.

alluxio-bot, merge this please.

alluxio-bot, cherry-pick this to branch-2.2 please.


Error when trying to preview file

Using vs code:
Version 1.22.1
Commit 950b8b0d37a9b7061b6f0d291837ccc4015f5ecd
Date 2018-04-06T02:26:57.615Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
Installed the plugin, configured dot path.
When I try to preview a dot file i get this error:
Unable to open 'Preview 'Untitled-1.txt'': An unknown error occurred. Please consult the log for more details..

Why did you close the issue?
Please tell me the cause.


First Response is empty in netlify when caching route

Server handler in netlify when cache is a miss and I've cached the route using useRouteCache the response is completely empty (no html no nothing), refreshing the page works as intended

This should now (hopfeully) be fixed in 3.3.0 due to refactoring how the route cache works. I can't test it myself for Netlify, but a similar issue popped up with Cloudflare Workers and there it now works.


Integrate CLI button with gRPC runner

This fixes the CLI button for use with the gRPC runner. Needs version of binary including stateful/runme#202 (built from main)
Not sure whether to pass everything as command line parameters, or environment variables. I used environment variables because it looks cleaner (and allows users to easily run other commands in the same session), but a lot is then "hidden" from the user. Thoughts @sourishkrout ?

Not sure whether to pass everything as command line parameters, or environment variables. I used environment variables because it looks cleaner (and allows users to easily run other commands in the same session), but a lot is then "hidden" from the user. Thoughts @sourishkrout ?

I was inclined to do the same. Mainly because with further explanation the flags aren't particularly self-evident and in this integrated way it makes sense for it to "just work".


Optimizer is transferring (almost) everything!

This is my config:
` {
"type":"PokemonOptimizer",
"config":{
"enabled":true,
"bulktransfer_enabled":true,
"max_bulktransfer":20,
"min_slots_left":25,
"action_wait_min":3,
"action_wait_max":5,
"transfer":true,
"evolve":true,
"debug":false,
"evolve_to_final":true,
"evolve_time":25,
"evolve_for_xp":true,
"evolve_only_with_lucky_egg":false,
"evolve_count_for_lucky_egg":80,
"may_use_lucky_egg":true,
"may_evolve_favorites":true,
"may_upgrade_favorites":true,
"may_unfavor_pokemon":false,
"upgrade":true,
"upgrade_level":30,
"groups":{
"gym":[
"Dragonite",
"Snorlax",
"Lapras",
"Tyranitar",
"Rhydon",
"Gyarados",
"Golem"
],
"my_love": [
"Pichu",
"Pikachu",
"Raichu",
"Lugia",
"Articuno",
"Zapdos",
"Moltres",
"Unown"
],
"trash": [
"!gym",
"!my_love"
]
},
"rules":[
{
"// Of all Pokemon with less than 124 candies, buddy the Pokemon having the highest maximum cp":{
              },
              "mode":"overall",
              "top":1,
              "sort":[
                 "max_cp",
                 "cp"
              ],
              "keep":{
                 "candy":-124
              },
              "evolve":true,
              "buddy":true
           },
           {
              "// Buddy the Pokemon having the less candies. In case no Pokemon match first rule":{

              },
              "mode":"overall",
              "top":1,
              "sort":[
                 "-candy",
                 "max_cp",
                 "cp"
              ],
              "evolve":false,
              "buddy":true
           },
           {
           "// Keep All Gym & My_Love, evolve or update if iv is greater than 0.9":{

              },

                   "mode":"by_pokemon",
              "names":[
                 "gym",
                 "my_love"
              ],
              "keep":true,
              "evolve":{
                 "iv":0.9,
                 "ncp":0.9
              },
              "upgrade":{
                 "iv":0.9,
                 "ncp":0.9
              }
           },
           {
              "// Keep two best iv of each type and evolve it if its iv is greater than 0.9":{

              },
              "mode":"by_pokemon",
              "names":[
                 "trash"
              ],
              "top":2,
              "sort":[
                 "iv"
              ],
              "evolve":{
                 "iv":0.9
              }
           },
           {
              "// Keep best cp of each type but do not evolve it":{

              },
              "mode":"by_pokemon",
              "names":[
                 "trash"
              ],
              "top":1,
              "sort":[
                 "cp"
              ],
              "evolve":false
           },
           {
              "// For Pokemon of final evolution and with iv greater than 0.9, keep the best two dps_attack":{

              },
              "mode":"by_pokemon",
              "names":[
                 "!with_next_evolution"
              ],
              "top":2,
              "sort":[
                 "dps_attack",
                 "iv"
              ],
              "keep":{
                 "iv":0.9
              }
           }
        ]
     }
  },`

However pretty much everything is being transferred, I am assuming it's a problem with the config rather than a bug, but I just can't seem to get my head around the logic, I have turned on debugging and this is the log file
https://dl.dropboxusercontent.com/u/9125175/pokemon-optimizer.log

Seems all good, but for sure the problem is in "trash" rule, remove it

@Jcolomar yep that seems to have worked, not sure what i was trying to do with the trash group.
Evolve and transfer seems good, don't think I have got anything that meets the rules for upgrading yet (using it on my new test account rather than anything with anything actually good) so will keep an eye on that going forward


FEATURE RQ : Data type sharing by default between executable and loaded libraries

Feature request :
As a ghidra user, i would like that, when loading an executable with its external libraries,
the function signatures and datatypes that are detected in the loaded library are available to the executable space by default
Let's say executable 1.exe loads a.dll and b.dll ,
on a.dll and b.dll analysis, the discovered data types and function signatures should be available to the analysis space of 1.exe
automatically (it loads them as libraries, it should be logic that the data known by ghidra about a library is reflected in the executable that uses it)
Manual archive creation and import is very labor intensive and repetitive (hence the job of a computer, not a human).

(for anyone who got here and is confused about the bad process referenced, the built in help in Help->Contents describes the functionality of Project Archives in the data type manager; this is slightly confusing naming because you can also archive a ghidra project to send to someone)
Anyway, time to wait for an indefinite length of time for the DWARF data to get drag/dropped into the archive 😭 . I wish the performance on this were faster.


[Fix] update pkg

I was used this, but it did not work with the latest version.
There was a deprecated method, so I fixed it.
Container#eachAtRule is deprecated. Use Container#walkAtRules instead.

In addition, I added a test case. Thanks.

Thanks!

Published to npm as<EMAIL_ADDRESS>


Updated the contributors pledge.

Pledged my cause for coding.

Thanks @RutvikJ77 for your PR. Welcome to the community.


Update _config.yml

Issue Fixed #
Proposed Changes

This commit is for your personal website :smile:
Closing the pull request.


Nonexistent function 'get_previous_nodes' in base 'Nil'

Hey! I'm sorry to have to disturb you again. But after I've added a few quests to my game today and everything looked good at first, I noticed a new bug at the end.
The error occurs after repeated serialization and deserialization:

var data : Array = Questify.serialize()
Questify.deserialize(data)
data = Questify.serialize() <--- Error accessing “_graph”

This problem did not exist before your last fix.
I've added a demonstration of the bug to the test scene here:
https://github.com/TheWalruzz/godot-questify/compare/main...ralf1991:godot-questify:serialize-error-demonstration
If I'm able to solve the problem myself, I will create a pull request. But at the moment I'm still going round in circles.

From my initial investigation, it has to do with how the data is deserialized. Nodes are not initialized properly after that, so serialization fails. I'll try to figure this one shortly

Fix is pushed, it should work again


fix: handle consecutive hyphens or underscores when formatting field …

…names

Checklist

[ ] run make test
[ ] PR title must follow conventional-commit-standard
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message and code follows the Code of conduct

good work


ZIP64 support is broken

I have a zip file which zip fails to open. Unfortunately I can't share it, however I've tracked the issue down to the zip64 extra field parsing.
Here's how zip currently handles it:
fn parse_extra_field(file: &mut ZipFileData, data: &[u8]) -> ZipResult<()>
{
    let mut reader = io::Cursor::new(data);

    while (reader.position() as usize) < data.len()
    {
        let kind = reader.read_u16::<LittleEndian>()?;
        let len = reader.read_u16::<LittleEndian>()?;
        match kind
        {
            // Zip64 extended information extra field
            0x0001 => {
                file.uncompressed_size = reader.read_u64::<LittleEndian>()?;
                file.compressed_size = reader.read_u64::<LittleEndian>()?;
                reader.read_u64::<LittleEndian>()?;  // relative header offset
                reader.read_u32::<LittleEndian>()?;  // disk start number
            },
            _ => { reader.seek(io::SeekFrom::Current(len as i64))?; },
        };
    }
    Ok(())
}

And here's how unzip (the command line tool which properly unpacks my zip file) does it:
int getZip64Data(__G__ ef_buf, ef_len)
    __GDEF
    ZCONST uch *ef_buf; /* buffer containing extra field */
    unsigned ef_len;    /* total length of extra field */
{
    unsigned eb_id;
    unsigned eb_len;

/*---------------------------------------------------------------------------
    This function scans the extra field for zip64 information, ie 8-byte
    versions of compressed file size, uncompressed file size, relative offset
    and a 4-byte version of disk start number.
    Sets both local header and central header fields.  Not terribly clever,
    but it means that this procedure is only called in one place.
  ---------------------------------------------------------------------------*/

    if (ef_len == 0 || ef_buf == NULL)
        return PK_COOL;

    Trace((stderr,"\ngetZip64Data: scanning extra field of length %u\n",
      ef_len));

    while (ef_len >= EB_HEADSIZE) {
        eb_id = makeword(EB_ID + ef_buf);
        eb_len = makeword(EB_LEN + ef_buf);

        if (eb_len > (ef_len - EB_HEADSIZE)) {
            /* discovered some extra field inconsistency! */
            Trace((stderr,
              "getZip64Data: block length %u > rest ef_size %u\n", eb_len,
              ef_len - EB_HEADSIZE));
            break;
        }
        if (eb_id == EF_PKSZ64) {

          int offset = EB_HEADSIZE;

          if (G.crec.ucsize == 0xffffffff || G.lrec.ucsize == 0xffffffff){
            G.lrec.ucsize = G.crec.ucsize = makeint64(offset + ef_buf);
            offset += sizeof(G.crec.ucsize);
          }
          if (G.crec.csize == 0xffffffff || G.lrec.csize == 0xffffffff){
            G.csize = G.lrec.csize = G.crec.csize = makeint64(offset + ef_buf);
            offset += sizeof(G.crec.csize);
          }
          if (G.crec.relative_offset_local_header == 0xffffffff){
            G.crec.relative_offset_local_header = makeint64(offset + ef_buf);
            offset += sizeof(G.crec.relative_offset_local_header);
          }
          if (G.crec.disk_number_start == 0xffff){
            G.crec.disk_number_start = (zuvl_t)makelong(offset + ef_buf);
            offset += sizeof(G.crec.disk_number_start);
          }
        }

        /* Skip this extra field block */
        ef_buf += (eb_len + EB_HEADSIZE);
        ef_len -= (eb_len + EB_HEADSIZE);
    }

    return PK_COOL;
} /* end function getZip64Data() */

The unzip's logic here is obviously very different.

I see that it was indeed not entirely correct. I have pushed some changes to master (in commit dbb871245), can you check if that resolves your issues? Otherwise I will need some more details on your zip file.

Thanks!
I don't have the zip file with me on hand right now, however before going home I did quickly poke and prod it to check why exactly it failed, and in that particular case the issue was that the header_start field wasn't updated.
I'm not sure if there is a formal spec for this, but can't we just do exactly what unzip does for all of the fields? E.g. something like this: (I actually planned to submit this as a PR, but you were faster. :sweat_smile:)
diff --git a/src/read.rs b/src/read.rs
index 3949cf4..6ca5ac5 100644
--- a/src/read.rs
+++ b/src/read.rs
@@ -328,7 +328,7 @@ fn central_header_to_zip_file<R: Read+io::Seek>(reader: &mut R, archive_offset:
     let file_name_length = reader.read_u16::<LittleEndian>()? as usize;
     let extra_field_length = reader.read_u16::<LittleEndian>()? as usize;
     let file_comment_length = reader.read_u16::<LittleEndian>()? as usize;
-    let _disk_number = reader.read_u16::<LittleEndian>()?;
+    let disk_number = reader.read_u16::<LittleEndian>()?;
     let _internal_file_attributes = reader.read_u16::<LittleEndian>()?;
     let external_file_attributes = reader.read_u32::<LittleEndian>()?;
     let mut offset = reader.read_u32::<LittleEndian>()? as u64;
@@ -367,6 +367,7 @@ fn central_header_to_zip_file<R: Read+io::Seek>(reader: &mut R, archive_offset:
         header_start: offset,
         data_start: 0,
         external_attributes: external_file_attributes,
+        disk_number: disk_number as u32
     };

     match parse_extra_field(&mut result, &*extra_field) {
@@ -409,10 +410,18 @@ fn parse_extra_field(file: &mut ZipFileData, data: &[u8]) -> ZipResult<()>
         {
             // Zip64 extended information extra field
             0x0001 => {
-                file.uncompressed_size = reader.read_u64::<LittleEndian>()?;
-                file.compressed_size = reader.read_u64::<LittleEndian>()?;
-                reader.read_u64::<LittleEndian>()?;  // relative header offset
-                reader.read_u32::<LittleEndian>()?;  // disk start number
+                if file.uncompressed_size == 0xffffffff {
+                    file.uncompressed_size = reader.read_u64::<LittleEndian>()?;
+                }
+                if file.compressed_size == 0xffffffff {
+                    file.compressed_size = reader.read_u64::<LittleEndian>()?;
+                }
+                if file.header_start == 0xffffffff {
+                    file.header_start = reader.read_u64::<LittleEndian>()?;
+                }
+                if file.disk_number == 0xffff {
+                    file.disk_number = reader.read_u32::<LittleEndian>()?;
+                }
             },
             _ => { reader.seek(io::SeekFrom::Current(len as i64))?; },
         };
@@ -614,6 +623,7 @@ pub fn read_zipfile_from_stream<'a, R: io::Read>(reader: &'a mut R) -> ZipResult
         // We set this to zero, which should be valid as the docs state 'If input came
         // from standard input, this field is set to zero.'
         external_attributes: 0,
+        disk_number: 0
     };

     match parse_extra_field(&mut result, &extra_field) {
diff --git a/src/types.rs b/src/types.rs
index a8609b3..c8f31c3 100644
--- a/src/types.rs
+++ b/src/types.rs
@@ -59,6 +59,8 @@ pub struct ZipFileData
     pub data_start: u64,
     /// External file attributes
     pub external_attributes: u32,
+    /// Disk number
+    pub disk_number: u32
 }

 impl ZipFileData {
diff --git a/src/write.rs b/src/write.rs
index ffcdfa2..f408254 100644
--- a/src/write.rs
+++ b/src/write.rs
@@ -214,6 +214,7 @@ impl<W: Write+io::Seek> ZipWriter<W>
                 header_start: header_start,
                 data_start: 0,
                 external_attributes: permissions << 16,
+                disk_number: 0
             };
             write_local_file_header(writer, &file)?;

A yes, this is largely the same I guess. After some thought, I think I need to take the header offset also in consideration (like you do), otherwise zip files larger than 4GB are not able to be parsed. I will do that soon, as some other things like the archive_offset also needs to be taken in consideration.

I think I have fixed the remaining issues in commits c286a8ba16 and bb38674a14. A test with a large zip64 file containing multiple entries now seems to work correctly.


[M3c][MetaScheduler] Add ReplayFunc and EvolutionarySearch Strategy.

This PR is part of the stage M3c of the meta schedule project (#8473).
The architecture is re-designed by Junru and Xiyou. In this PR we introduced two more variants of search strategy, replay func and evolutionary search. The ReplayFunc search strategy utilizes schedule functions to explore the search space while the evolutionary search strategy utilizes a cost model to effectively find candidates which are preferred to have high score, i.e., potentially very fast running time.
Unittests are also updated in this PR. Thanks to all co-authors for contributing!
Note: The PR currenlt includes PR #9789 and will rebase once it's merged.
Co-authored-by: Junru Shao<EMAIL_ADDRESS>Co-authored-by: Bohan Hou<EMAIL_ADDRESS>Co-authored-by: Ruihang Lai<EMAIL_ADDRESS>Co-authored-by: Hongyi Jin<EMAIL_ADDRESS>Co-authored-by: Wuwei Lin<EMAIL_ADDRESS>Co-authored-by: Siyuan Feng<EMAIL_ADDRESS>

Please split this PR into two separate ones: ReplayFunc and EvolutionarySearch

Please split this PR into two separate ones: ReplayFunc and EvolutionarySearch

Let's rebase this PR on the latest HEAD given #9789 is merged. Then dedicate this PR to ReplayFunc only, and split evo search as another PR

Fixed as suggested, ready for review. Follow up PR later.


Push notifications into inbox

We must be able to push a notification into receiver's inbox whenever the sender sends a message

All done, however, might be worth it to create a folder inside the inbox with more permissive permissions.


L&S - Victory condition quest

To go with the MacGuffin in #560 we need an actual "victory quest" which likely is bringing said item back from the enemy base to the home base and placing it in the very inner sanctum next to the home MacGuffin.
If the player picks up the enemy MacGuffin the quest should remain active either until victory or the player is killed, in which case the quest should trigger a failure (but not game defeat) condition where the MacGuffin either spawns where the player died or reappears back home.
Could also be traditional CTF where the item drops and any player can pick it back up - if a friendly then the object warps back home immediately.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/486293-l-s-victory-condition-quest?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github).

Moved to https://github.com/Terasology/LightAndShadow/issues/23.


add check for source annotation property on xref axioms

xrefs axioms should only be annotated with oio:source and skos values.
Related to #28404.

FYI, I see 4 such examples of this error in the current ontology:
id: GO:0004764
name: shikimate 3-dehydrogenase (NADP+) activity
xref: EC:<IP_ADDRESS>2 {comment="skos:broadMatch"}
(I'm fixing this one as part of #28514)
id: GO:0018423
name: protein C-terminal leucine carboxyl O-methyltransferase activity
xref: RHEA:48544 {comment="skos:narrowMatch"}
id: GO:0047224
name: acetylgalactosaminyl-O-glycosyl-glycoprotein beta-1,3-N-acetylglucosaminyltransferase activity
xref: RHEA:46884 {comment="skos:narrowMatch"}
id: GO:0051698
name: saccharopine oxidase activity
xref: RHEA:28210 {comment="skos:exactMatch"}

I fixed the 4 problematix xref types.


Fix expected argument mismatch message on Puppet 4.3.0

The exception message raised under Puppet 4.3.0 for arity mismatches in
functions changed:
expected split("foo") to have raised ArgumentError matching /mis-matched arguments/
instead of ArgumentError('split' expects 2 arguments, got 1)

:+1:


Write a Java program to find sum of n natural numbers using formula

Description
Write a Java program to find sum of n natural numbers using formula
formula: n(n+1)/2
Input  : 5
Output : 15

How to contribute

Save the solution in FindSumOfNNaturalNumbersUsingFormula.java file
Add FindSumOfNNaturalNumbersUsingFormula.java file in program/find-sum-of-n-natural-numbers-using-formula folder

!assign

Hey @dineshlalam15,
This issue has been assigned to you for more than 15 days.
We are unassigning you from this issue.
If you are still interested in contributing to this issue, please get auto-assigned on the issue by commenting !assign again.
Thanks for your contributions :)


Dashboard not loading Executables (sometimes)

Sometimes on app startup the dashboard does not list the executables like npm apps. This behaviour is not consistent and happens randomly from what I've seen. The executable is working, if I open a new tab with the url of the executable, it works.
No errors on console or network tabs.
Might be because I have a lot of aspire components. On the sample with React/Vue/Angular I'm unable to replicate.
I have the following components:

1 container
4 parameters
8 projects
1 executable (not showing)

Sometimes I'm able to fix it by changing something on my AppHost\Program.cs file (forcing recompile).
Might be related with https://github.com/dotnet/aspire/issues/2539
On: 8.0.0-preview.5.24128.10

@balachir can you keep an eye out for this one as well? This is on the main branch so not urgent right now.

@davidfowl sure, we'll try it and see if we can repro with main branch builds.

I was able to reproduce this and fix it

@davidfowl @balachir I tried to verify this issue with the AspireWithNode and AspireWithJavaScript samples from aspire-samples repo but was unable to reproduce it using the latest Aspire 8.0 P5 (8.0.0-preview.5.24154.5).


Bug: Incorrect adjustment of column widths in autofit method with autofilter headers

Current behavior
The autofit method in the Worksheet struct incorrectly identifies autofilter header cells, causing improper adjustment of column widths. When autofilter is applied and date headers are added, the method does not consider the additional width occupied by these headers.

Expected behavior
The autofit method should accurately identify autofilter header cells, including the additional width occupied by date headers, and adjust the column width accordingly.

Sample code to reproduce
use rust_xlsxwriter::{Workbook, XlsxError};

fn main() -> Result<(), XlsxError> {
    let mut workbook = Workbook::new();
    let worksheet = workbook.add_worksheet();

    // Set autofilter
    worksheet.autofilter(0, 0, 3, 3).unwrap();

    // Add data
    worksheet.write_string(0, 0, "Header 1")?;
    worksheet.write_string(0, 1, "Header 2")?;
    worksheet.write_string(0, 2, "Header 3")?;
    worksheet.write_string(0, 3, "Header 4")?;

    // Add content
    worksheet.write_string(1, 0, "Data 1")?;
    worksheet.write_string(1, 1, "Data 2")?;
    worksheet.write_string(1, 2, "Data 3")?;
    worksheet.write_string(1, 3, "Data 4")?;

    worksheet.write_string(2, 0, "Data 5")?;
    worksheet.write_string(2, 1, "STRATEGIC MANAGEMENT WITH A MENTION IN INNOVATION AND MANAGEMENT IN HIGHER EDUCATION")?;
    worksheet.write_string(2, 2, "Data 7")?;
    worksheet.write_string(2, 3, "Data 8")?;

    worksheet.write_string(3, 0, "Data 9")?;
    worksheet.write_string(3, 1, "Data 10")?;
    worksheet.write_string(3, 2, "Data 11")?;
    worksheet.write_string(3, 3, "Data 12")?;

    // Autofit
    worksheet.autofit();

    // Save file
    workbook.save("test.xlsx")?;
    Ok(())
}

Environment
- `rust_xlsxwriter` version: 0.64.2
- Cargo.toml dependency line for `rust_xlsxwriter`: rust_xlsxwriter = "0.64.2"
- rustc version: rustc 1.77.2 (25ef9e3d8 2024-04-09)
- Excel version: -
- OS: Windows 10
- If using wasm, which method/tool: -

Any other information
In the autofit function (pub fn autofit(&mut self) -> &mut Worksheet {...}) of the Worksheet struct (worksheet.rs), the condition for identifying autofilter header cells is incorrect. It currently uses the row_num variable instead of the first_row property of the Worksheet dimensions. This causes the method to improperly adjust column widths.
// Incorrect condition
if pixel_width > 0 && self.cells_with_autofilter.contains(&(row_num, col_num)) {
    pixel_width += 16;
}

// Corrected condition
if pixel_width > 0 && self.cells_with_autofilter.contains(&(self.dimensions.first_row, col_num)) {
    pixel_width += 16;
}```

The autofit method in the Worksheet struct incorrectly identifies autofilter header cells, causing improper adjustment of column widths.

I don't think that is the case. In the first example the column is autofitted correctly to the text width.
Also, the additional 16 pixel allowance for header cells is to prevent the dropdown arrow from obscuring the fitted text, like this:

I'm guessing that the "expected behaviour" example is an example of Excel's autofit. One thing to note about that is that the autofit width is the same regardless of whether the autofilter is on or off. The difference between the rust_xlsxwriter and Excel output is explained in Notes on the XlsxWriter implementation of autofit(). Particularly in the section on "Fidelity with Excel".
The bug report mentions "dates" a few times but the example doesn't show any. In order to save time I'll point out that dates aren't currently handled properly since they have a separate number format that dictates the width of the cell. From the limitations section in the docs on autofit() it says:

It doesn’t take number or date formatting into account, although it may try to in a later version.

That is still the case.

Closing as won't/can't fix.


BatchSize settings

Hi,
Great work~ Thanks.
I have a question: Why the batchsize is only 16 in paper experiments, what will happen if I set it as 128, 256 or larger?

We use 2080TI for training, and the batch size is limited by insufficient graphic memory. I guess the training will be more stable if you set up a larger batch size.


Build instructions

I notice that the current build, using make, seems hard-coded to a certain environment (e.g. server name and username). It's also a little heavyweight for hacking around and checking things do/don't work (Docker, etc.) If it's possible to build outside of this environment would it be possible to get some minimal build instructions in the README? I ask because I'd like to make a change to the client to support specifying server port (similar to the change I made on the server side) but don't want to just throw something at you that may or may not even build :D

Thank you! It is true that things are currently a bit hard-coded, and in all honesty, even I can't actually run all of the tests on my local machine (since there are a lot of integration tests that cover all kinds of complex scenarios). But I definitely agree and welcome all contributions so I added some info to the README to help with this. But also, feel free to just open a PR and let Github Actions run and that works great for me. :)
Please let me know if there is anything else I can help answer!

Ah fantastic - thank you David! I'll get back on this next weekend :)

Sounds great! I'll go ahead and mark this as closed, but please re-open it if there is anything else I can help document.


TypeError: * is not a function after bundled

Describe the bug
// src/index.ts
import getopts from 'getopts'

const args = getopts(process.argv.slice(2), {
    alias: {
        watch: 'w',
        target: 't',
        outDir: 'o',
        project: 'p',
    }
})

After code bundled, calling function has an error getopts is not a function. I find something wrong in the output file.
function __spack_require__(mod) {
    var cache;
    return function() {
        if (cache) {
            return cache;
        }
        var module = {
            exports: {
            }
        };
        mod(module, module.exports);
        cache = module.exports;
        return cache;    // no 'default' property is returned here
    }();
}
...
var load = __spack_require__.bind(void 0, function(module, exports) {
    ...
    module.exports = function(argv, opts) { ... }    // same here, no 'default'
});

var { default: getopts  } = load();    // but here set ’default‘ value to getopts

Config
// spack.config.js
const { config } = require('@swc/core/spack')

module.exports = config({
    entry: {
        index: __dirname + '/src/index.ts',
    },
    output: {
        path: __dirname + '/bin',
    },
})

Is anything I haven't noticed in this config?
Version
The version of @swc/core: 1.2.58

This happens with named imports too (using v1.2.90)
Just started playing with swc, but it appears that __spack_require__ only appears with a non-relative import, so here's a minimal reproduction using<EMAIL_ADDRESS>import { Router } from 'worktop';
import { reply } from 'worktop/sw';

const API = new Router;

API.add('GET', '/', req => {
	return new Response('OK');
});

reply(API.run);

Search for finalize and STATUS_CODES in the output. They're nowhere in the source.
In larger builds, the source/definitions do exist in the output but are never destructured from the load() assignment.

Hi there!
I'm facing the same problem. Is there any solution?
All the imports in the shape of import * as something from ... output the same problem


Progress Bar problems with Remove-AppxPackage

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
This script will demonstrate the problem by removing and re-installing the Calculator app.  (It requires Administrator privileges to be able to re-install the app.)
BugInRemove-AppxPackage.zip
The work-around to re-displaying the progress bar is to run the cmdlet in a new shell.  e.g.
$Env:AppxPackageName = $AppxPackage.Name
. (Get-Process -Id $PID).Processname  -Command 'Get-AppxPackage $Env:AppxPackageName | Remove-AppPackage'
Expected behavior
The progress bar should honor the ProgressPreference and never re-display after the cmdlet completes.

Actual behavior
Remove-AppxPackage does not honor $ProgressPreference = 'SilentlyContinue'.

Then, the progress bar is re-displayed and remains in view if the command is followed by [System.Console]::ReadKey().

These are probably two seperate bugs, but tied closely together.

Error details
No response
Environment data
The problem exists in V5.1 and V7.3.1

Visuals
No response

Pragmatically speaking, using pause instead of [Console]::ReadKey() is a simple workaround that can make a lingering progress bar disappear (though I'm not sure why); a simple demonstration:
# With [Console]::ReadKey(), the status bar would linger.
Write-Progress -Activity Test -Status  '100% complete'; Start-Sleep 2; pause

The root problem is that the Appx cmdlets apparently do not call Write-Progress -Completed, which means that PowerShell will eventually hide the progress bar automatically, but not until after the script at hand has terminated.
As for honoring $ProgressPreference:

As a shell-only variable, it isn't available across process  boundaries, so the code you're passing to . (Get-Process -Id $PID).Processname  -Command will not see the caller's value (btw, a better way to call via a child process is pwsh { Get-AppxPackage $args[0] | Remove-AppPackage } -Args $AppxPackage.Name

Even in-process, however, there's a wrinkle: since the AppX module in PS Core is loaded via the Windows PowerShell Compatibility feature, it uses implicit remoting via a script module, and functions in script modules do not see the caller's preference variables, unless they're defined in the global scope (e.g., $global:ProgressPreference = 'SilentlyContinue'), which requires explicitly restoring the previous value afterwards, so as not to affect subsequent code.

This is a longstanding problem; see #4568 for details.

I forgot about the alternative: you can call Write-Progress -Completed yourself, but, unfortunately, this requires you to supply a dummy -Activity argument; e.g.:
Write-Progress -Activity Test -Status '100% complete'; Start-Sleep 2; Write-Progress -Activity '(dummy)' -Completed; [System.Console]::ReadKey()

The unexpected need for an -Activity argument is the subject of #15252

I previously tried calling "Write-Progress - Activity 'dummy' -Complete" and that did not work.  I also tried creating a new progress bar and clearing it, but the old progress bar remained.
I also tried using pause right after the call and that did not protect the next ReadKey, which I was using to make a menu selection.  The menu display was trashed.
BTW, thanks for the better code idea, now using:
. (Get-Process -Id $PID).Processname { $args[0] | Remove-AppPackage } -Args $AppxPackage

Let's try to narrow this down:

With direct calls, doesn't setting $global:ProgressPreference = 'SilentlyContinue' solve your problem?

It is plausible that the implicit remoting involved in direct calls to (the proxy commands for) the AppX module thwarts the Write-Progress - Activity 'dummy' -Complete workaround. (I haven't tried, given that you shouldn't expect others to download source code just to reproduce your symptom).

Let's try to narrow this down:

With direct calls, doesn't setting $global:ProgressPreference = 'SilentlyContinue' solve your problem?

It is plausible that the implicit remoting involved in direct calls to (the proxy commands for) the AppX module thwarts the Write-Progress - Activity 'dummy' -Complete workaround. (I haven't tried, given that you shouldn't expect others to download source code just to reproduce your symptom).

I just tested $global:ProgressPreference = 'SilentlyContinue' and it does prevent the progress bar from appearing.  I looked in the documentation and saw nothing about when to specify global preference variables.  I did find this came up over 3 years ago in https://github.com/PlagueHO/CosmosDB/issues/308.
The script that I submitted was specifically written to demonstrate the problem and short enough to examine before running.  The problem does not present itself outside of a script and describing how to write the script seemed too cumbersome.  But I understand your reluctance, especially with the Administrator requirement to replace the deleted app.

First, a meta comment:

I dug deeper, and realized that I had some misconceptions and that some of what I suggested wouldn't help.

Notably, I found $global:ProgressPreference = 'SilentlyContinue' not to be effective: while the point about script modules only seeing preference variables if they're defined in the global scope is correct (see #4568), it seems that the additional factor of implicit remoting being involved makes the workaround ineffective.
I think it is due to the fact that the progress display must be silenced at the source, and the automatically generated local proxy script module makes no attempt to pass the local value on.

This may be worth reporting as a separate bug.

On a side note, a -ProgressAction common parameter is coming (though it wouldn't help here): see #18887

I've hidden my previous comments and will post a - hopefully  now correct - summary below.

It is commendable that you prepared detailed code to demonstrate the problem, but to make it easier for others to run it, please in general add it directly to your post, not as an attachment, ideally in the form of a minimal example.

The root problem is that the Appx cmdlets apparently do not call Write-Progress -Completed (or make an equivalent .WriteProgress()  method call, given that they are binary cmdlets) in order to remove the progress bar on completion, which means that PowerShell will eventually hide the progress bar automatically, but not until after the script at hand has terminated.

As such, the problem should be reported against the  Appx module, which is not maintained in this repo. The module's doc page has a "Feedback" section that suggests the Feedback Hub app should be used.

Given that properly removing a progress bar isn't enforced by syntax / tooling, the problem is likely to affect other modules as well.

In your case, since you're using an interactive feature that delays completion of the script - [Console]::ReadKey() - the progress bar lingers at that point.
(Interactive features provided by PowerShell - such as pause - may mask the problem, because they temporarily hide a progress bar, but they actually restores it afterwards).
As for workarounds:

Silencing the progress display altogether with $ProgressPreference = 'SilentlyContinue' is normally an option, but not in this particular case, given that the Appx module is loaded via the Windows PowerShell Compatibility feature, which involves implicit remoting via a proxy script module that is generated on demand, and this module seemingly does not relay the preference, even if set globally (which script modules in general require, unfortunately (see #4568)).

However, the workaround you came up with - calling via a child PowerShell process, using PowerShell's CLI - is effective, and even allows you to choose to display the progress bar, relying on the fact that the PowerShell child process automatically hides it on exiting:

In this case, given that Windows PowerShell is ultimately called anyway, the workaround can be optimized by always calling powershell.exe. Aside from paying a performance penalty (if you call more than once), no functionality is lost.
# With progress display
powershell.exe -NoProfile { Get-AppxPackage $args[0] | Remove-AppPackage } -args $AppxPackage.Name

# Without progress display
powershell.exe -NoProfile { $ProgressPreference = 'SilentlyContinue'; Get-AppxPackage $args[0] | Remove-AppPackage }  -args $AppxPackage.Name

Generally, in cases where implicit remoting is not involved by default, a CLI-based workaround comes with potential loss of type fidelity, however (a price you invariably pay when implicit remoting is involved).

Hiding another command's lingering progress bar on demand with Write-Progress -Activity 'unused' -Completed works only if the progress bar was put up from PowerShell code with Write-Progress too and without using an -Id argument.

Thank you for that detailed resolution.  I have reported this problem on the Feedback Hub as "Remove-AppxPackage does not close the progress bar".


Download links for previous versions

Could you provide download links to previous versions? I've just upgraded to 1.5.0 and I'm having issue connecting to storage account now (both azure and emulator). I would like to rollback to the previous version but no download links are available.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 337c96d2-0b4f-ad70-bb7a-cf8d6736cc3c
Version Independent ID: 09c7c658-16d1-04ac-6bb4-6aa5c1b529a6
Content: Get started with Storage Explorer
Content Source: articles/vs-azure-tools-storage-manage-with-storage-explorer.md
Service: storage
GitHub Login: @CawaMS
Microsoft Alias: cawa

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

#in-progress

To unblock the scenario, all versions can be downloaded here: https://github.com/Microsoft/AzureStorageExplorer/releases

I will include the link in release notes. Please close this particular issue.

#please-close


Add neo4j vector index docs

Docs for https://github.com/langchain-ai/langchainjs/pull/2852

Thank you!


includeInitial in .changes()

Hi,
Only 'squash' and 'includeStates' options seems available on the .change() command.
Adding 'includeInitial' would be interesting.
Ber.

@chocolat2000 should be a matter of adding it here

Closing as duplicate, let's track all the issue for 2.2 in one issue: #177


[problem] edge case when creating transactions to self

When I parse a payment_uri with an integrated address like:
"monero:5F2AGUyXjR3bvX38GaAsARaQ1exeBCVkUbPTfGssBfXQ5VPor4eA144YpUE7FNg5bLcpEuehNne23MkG8ZMCkPEegecygCNXsmd1CnEenm?tx_amount=0.250000000000"
and pass the MoneroTxConfig to createTx I get this error:
Uncaught (in promise) RuntimeError: Aborted(Assertion failed: R == dbg_R, at: /Users/woodser/git/monero-javascript/external/monero-cpp/external/monero-project/src/crypto/crypto.cpp,450,generate_tx_proof). Build with -sASSERTIONS for more info.
I get the same error when I manually create a MoneroTxConfig with the integrated address.
So I assumed I ought to use decodeIntegratedAddress(integratedAddress) and pass the Standardaddress and PaymentId manually into the MoneroTxConfig. But when I do this, I get this error:
Error: Standalone payment IDs are obsolete. Use subaddresses or integrated addresses instead
    at LibraryUtils.WORKER_OBJECTS.<computed>.callbacks.<computed> (LibraryUtils.js:212:1)
    at Worker.LibraryUtils.WORKER.onmessage (LibraryUtils.js:188:1)

So it seems like the paymentId field for the MoneroTxConfig is the old style paymentId.
Creating transactions to standardaddresses works.
This was the code that I used on the server side to create the payment uri from this standard address:
75jZRMyxRMjbvX38GaAsARaQ1exeBCVkUbPTfGssBfXQ5VPor4eA144YpUE7FNg5bLcpEuehNne23MkG8ZMCkPEeTqtwPsG
async function(wallet, standardAddress, amount){
    wallet = await wallet
    let networkType = await wallet.getNetworkType();
    // get integrated address with randomly generated payment id
    await LibraryUtils.loadKeysModule();
    let integratedAddress = await MoneroUtils.getIntegratedAddress(networkType, standardAddress);
    //let paymentId = integratedAddress.getPaymentId(); // 16 characters write this to req.app.locals.payment or write it to the session
    let paymentUri = await wallet.createPaymentUri(new MoneroTxConfig().setAddress(integratedAddress.getIntegratedAddress()).setAmount(new BigInteger(amount)))
    return paymentUri;
}

maybe I messed up there somehow. It seems like I dont get out the same standard address that I put in. I will  make a paymenturi with just a standard address and see if that works. EDIT: It works. So this issue most likely arises because I make faulty integrated addresses. I will verify again with a know good integrated address.
A known good integrated address produced a different error message:  Invalid destination address     at LibraryUtils.WORKER_OBJECTS.<computed>.callbacks.<computed> (LibraryUtils.js:212:1)     at Worker.LibraryUtils.WORKER.onmessage (LibraryUtils.js:188:1)
so it seems like it still needs to be processed somehow before it can be fed into createTx.
EDIT again: this might be  because the known good address is a mainnet address and I a m on stagenet. So maybe integrated addresses work fine, I just picked the wrong net. In either case the error message is less spooky
EDIT again AGAIN: I tried again with a stagenet integrated address. This time it worked without issues. So the issue is narrowed down to the integrated address creation process. I think it might lead to trouble because I use Moneroutils to generate an integrated address for a wallet that is different from the wallet that is currently opened with monerowalletfull. I want to do this because the backend should be able to create new integrated for addresses of users that we dont have the viewkeys for.
EDIT. the integrated address from above works when creating a transaction with the gui wallet, but it still produces the same error when creating a transaction with this library. I setloglevel to 10 but it didnt gain any new insights. I will try further and figure out where the issue is :-)
EDIT: I think I can reproduce it now: 1.create subaddress. 2. make integrated address with subaddress 3.create transaction to this integrated address. => leads to the crash with "Assertion failed: R == dbg_R," Conditions: it needs to be a subaddress of the same wallet. ( so essentially sending to ones own wallet subaddress with an embedded payment id leads to this it. side effect: decodeIntegrated address also leads to unexpected output with this address)  Monero GUI also shows an error message for this. the question is how to best deal with it. getting users to create these tx leads to crashes. I will write a test case for this when I have more time.

I was able to reproduce the issue. Thanks for reporting.
The problem is integrated addresses cannot be created from subaddresses.
monero-javascript-v0.7.1 is released to which throws an error if a subaddress if provided. Thanks!

related commit https://github.com/monero-ecosystem/monero-javascript/commit/c49b791567899bb3cd4d2ff944743a1b5cc67f0d
I am sorry but I think this fixes the wrong thing. Creating integrated addresses from subaddresses is supported. It is just that the wallet-rpc for example does not implement this feature.
The issue is that somebody could still create these addresses with the old version or a different tool.
The real issue is that the createTx produces a crash in the edge case that we send a transaction to "ourselves".
If we createTx  to a different wallet that used a subaddress to create an integrated address it works just fine.
Steps to reproduce:
1.create two wallets. 2.create an integrated address from a subaddress with wallet A. 3.create a transaction in wallet B to this address.
You will see it works if you use wallet B but it will  produce the crash if you use wallet A ( the one that owns the subaddress)
the limitation to not allow integrated addresses from subaddresses does not exist in practice (as we can see everything works fine as long as it is a different wallet we send the money to). This limitation also shouldn't exist because there are valid usecases for this.
I have one of these usecases:
https://www.youtube.com/watch?v=4DLcsQ45zoE
I implemented this clubcards feature in my browser wallet ( will set the repo to public soon under MIT so everyone can see in detail how it works)
I want to give the users the ability to login to websites with a subaddress. The website will  have monero-javascript running and will create integrated addresses for these users. (which will then be the payment addresses of these clubcards that other users of the website can buy) The website obviously shouldn't have the viewkeys of the users and they should also only have this one subaddress per user.
A better fix would be to detect if the integrated address we input to createTx is  made from a subaddress that belongs to us and in this case make sure the crash does not happen by refusing to create the transaction.
An even better fix would be to get to the bottom of why this error happens in the monero codebase.
It is unclear why it is possible to send to these kind of addresses if it is a different wallet, but if it is the currently opened wallet it will lead to a crash.
Thank you very much and sorry for the inconvenience!

I'm happy to support whatever's possible. I asked about integrated subaddresses on #monero-dev. Unfortunately it sounds like integrated subaddresses are not to be used:
woodser
are integrated subaddresses permissible and supportable? monero-wallet-rpc does not support it. one can manually call the same utilities to create integrated subaddresses, but there seems to be a problem when sending funds to self with one of these

moneromooo
No.
Subaddresses were made to avoid having the two part addresses, which confused users as they had two addresses that looked different but sent to the same address.
Well, that's one reason at least.

This feature would diverge from official support which is not comfortable.
what does official support mean? Is it documented somewhere?
Do we have any guarantees it works for all integrated subaddresses except when sending to self?
yes. I tried this both with monero-javascript and the monero-gui and it both worked. I can also try with wallet-rpc if you want, it will most likely work too.
You can see in the Address analyzer by brunner that I linked that it is all just public view and spend keys after all. The wallet cant tell the difference.

By official support, I mean supported by the software in monero-project.
Monero GUI allows generating integrated subaddresses, or only sending to integrated subaddresses (which could be an oversight)? What happens if sending to self using an integrated subaddress in Monero GUI?

If the Monero GUI crashes sending to self with an integrated subaddress, mind opening an issue on monero-project? Even if integrated subaddresses aren't officially supported there, they shouldn't crash the wallet.
It would be helpful to include a link to a tool to generate the integrated subaddress or include a sample mnemonic and corresponding integrated subaddress.

Even if integrated subaddresses aren't officially supported there, they shouldn't crash the wallet.

they dont crash the wallet. Neither monero-javascript nor the monero gui crashes when the "integrated subaddresses" belong to a different wallet. Everything works fine. The transaction is created and sent. Because the wallet cant tell the difference between the public keys of a primary address or a subaddress.
The only case where the error happens is  when the "integrated subaddress" belongs to the same wallet the transaction is created on. That is a weird minor edge case and it seems like I am the first one that came across this. So I dont think it is necessary to introduce this artificial restriction that serves no purpose and means I have to maintain my own fork where these restrictions dont apply.
This is the error message that the GUI produces. It does not crash the whole program like with monero-javascript, but it certainly looks weird:

I got more feedback for integrated subaddresses:
moneromooo
It would just fuck up the efforts people made to improve things, but it'd work.
If one wanted to avoid being an jerk about it, one might make their own custom address format that's obviously not monero, ie "custommagicstringHEREGOESPUBKEYS". That would go a long way towards making people realize those aren't monero addresses, just identifiers for whatever code uses them.
Or even something like moneroaddress+64bitnumber
Then it'd be obvious the addresses are the same when the extra payment id is removed.
In fact, monero:ADDRESS&payment_id=x
I knoew it'd come in handy at some point :D
Thought ought to be given to how to make it not dumb on chain. I'm not sure a dummy payment is added when all outs are subaddresses atm. If this is not the case, those txes would stick out.
But then I suppose the goal isn't to blend in if trying to ram a feature through on the side :/
There are two things really (that I remmeber off the top of my head). The user confusion and the on-chain distinguishibility.

Let's open an issue for the error when sending to self with an integrated address in Monero GUI / monero-wallet-rpc. The core wallet should be able to handle that edge case since the underlying keys are the same.
Re: "monero:ADDRESS&payment_id=x", do you know if sending to a subaddress with a separate payment ID works? IIRC the wallet prevents it.
In the meantime, we can re-enable generating them in the library and gracefully error when sending funds to self.

Re: "monero:ADDRESS&payment_id=x", do you know if sending to a subaddress with a separate payment ID works? IIRC the wallet prevents it.

this is a bad idea and should not be used because it is the "old style of using payment ids". Integrated addresses were introduced to solve exactly this issue, among others. (that is when the new 8 bit "compact" payment ids were introduced., they will be hidden in the transaction so external observers cant link it. Source: https://monerodocs.org/public-address/integrated-address/#integrated-addresses-vs-subaddresses
There is nothing new that needs to be implemented, as we can already send and create these kind of "integrated subaddresses" as you called it. There was just this little edge case bug that I reported.
I think maybe the title of this issue is a bit misleading because I didn't know what I was up against when I first started out. (it turned out to be a much smaller problem than expected)

https://github.com/monero-ecosystem/monero-javascript/commit/c49b791567899bb3cd4d2ff944743a1b5cc67f0d seems like a correct fix. Integrated subaddresses are not supported by the core implementation for a variety of reasons, as explained by mooo's IRC comments.
Just because something is technically possible doesn't mean it's a good idea.

Just because something is technically possible doesn't mean it's a good idea.

maybe it would be better to block sending to primary addresses when they are part of integrated addresses. They are the thing that is legacy after all and not subaddresses.
This way we could also solve any distinguishability issues that might arise.


Captcha not working

When attempting to register after successful captcha completion the register page will show that the captcha has been failed

It's has any error in console?

there isn't


request(Permissions.PERMISSIONS.IOS. BLUETOOTH_PERIPHERAL) returns unavailable after pressing OK on iOS version 13

Hello everyone!
I've faced an issue regarding request functionality in iOS. I'm trying to request the Bluetooth service permission and after pressing OK to allow my application to use the Bluetooth, the request returned Unavailable, when I'm expecting to receive Granted status. After that, any attempt to enable Bluetooth ends with the app crash. I will add a screenshot below. On pressing Don't allow it returns Blocked status as it should. It basically means that functionality is not available for usage, even with allowing to use it. Does anyone have a similar issue?
Thank you in advance.
Steps to reproduce:

Launch app with react-native-permissions library
Perform request(PERMISSIONS.IOS.BLUETOOTH_PERIPHERAL)
Press OK. The request returns the unavailable response
Enable Bluetooth

Received error message:

NOTES:

Using a real device (iPhone XS)
iOS 13.3 version
Both NSBluetoothAlwaysUsageDescription and NSBluetoothPeripheralUsageDescription were added to Info.plist

@BohdanIvanov Did you added bluetooth-peripheral in your app supported capabilities?

@zoontek Didn't notice any bluetooth-peripheral option in capabilities inside of Xcode. Can you please share a screenshot?

Sure (Bluetooth peripheral = Acts as a Bluetooth LE accessory)

@BohdanIvanov Any progress?

@zoontek Sorry that couldn't answer earlier. For now, I've decided to go another way, without using the request method. I'll try to test in the nearest time and will let you know. Thank you :)

I tried the mentioned steps but bluetooth permissions are not working. I am using iOS 14.2

Also seeing this :( not working ios 14.

The critical question @dorthwein is this I think:

@BohdanIvanov Did you added bluetooth-peripheral in your app supported capabilities?

...additionally it appears the example app tests every single one, does the example app demonstrate this one? Worth confirming, and if it does, does the example app work?

Does it still work on iOS real device for Bluetooth on iOS 17.5 if I have followed all steps above?

If you're encountering the issue where requesting Bluetooth permission returns unavailable, add this line to your iOS -> Podfile: pod 'Permission-BluetoothPeripheral', :path => "../node_modules/react-native-permissions/ios/BluetoothPeripheral" and rebuild your app to resolve the issue. I'm using version 17.5.
@zoontek thanks !

@esiltu Or read the documentation.


Python: add py3.12 to CI

Motivation and Context

fixes: https://github.com/microsoft/semantic-kernel/issues/5144
Description

Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

@microsoft-github-policy-service agree

Thanks for taking a look at this, but I already have a PR (#5191) going for this, and it is not as easy as I hoped.

Great!
When I was checking #5144, there were no linked PRs, so I started this task. :smile:


sql generated in log is wrong

What version of Go and system type/arch are you using?
go1.20.10 darwin/amd64
What version of GoFrame are you using?
v2.6.1
Can this bug be re-produced with the latest release?
yes
What did you do?
query with in filter, sql generated in log is wrong.
What did you expect to see?

What did you see instead?

没有复现，请提供复现代码。
github.com/gogf/gf/v2 v2.6.1
dao.EventTask.Ctx(ctx).WhereIn(dao.EventTask.Columns().TaskStatus, g.SliceStr{consts.TaskStatusUnprocessed, consts.TaskStatusProcessing}).All()
SELECT * FROM `event_task` WHERE `task_status` IN ('unprocessed','processing')

没有复现，请提供复现代码。
github.com/gogf/gf/v2 v2.6.1
dao.EventTask.Ctx(ctx).WhereIn(dao.EventTask.Columns().TaskStatus, g.SliceStr{consts.TaskStatusUnprocessed, consts.TaskStatusProcessing}).All()
SELECT * FROM `event_task` WHERE `task_status` IN ('unprocessed','processing')

The SQL that is actually executed is fine, but the SQL printed in the logs is problematic.
You can try to generate a query with two in filters and then check the log generated in logs.

We add some trace info into the sql hint, something like /* p=Eros,i=d0e3d7953427d4174bb17f2d3d0b9c95,f=GET /api/v1/oss/task?statuses=[%22Failed%22,%22Closed%22] */.
There is a placeholder ? in it which cause this issue.


Add django-conf to encapsulate settings

@khchine5
Can you add django-appconf to the setup.py install requires?
install_requires=[
        "django-appconf>=1.0.1"
]

@paltman Done.

@khchine5 since the app label is pinax_comments, the settings names will be prefixed with PINAX_COMMENTS_. Also, in the app conf declaration you should just use the suffix (e.g. CAN_DELETE_CALLABLE).

@paltman  I have fixed the issues and all tests pass now.

@khchine5 awesome sauce! thanks!


docker restarts containers before containerd socket is opened

Hi,
Description
For a few days, my flatcar server doesn't reboot containers (set to always).
Impact
Since updates triggers reboot, I often have all my services down :-((
Environment and steps to reproduce

Create a container with restart policy as always
reboot

Expected behavior
I expect the containers to successfuly restart.
Additional information
My server is migrated from coreos. I disabled docker.socket and enabled docker.service according to #175, using systemctl enable --now docker.service and systemctal disable --now docker.socket.
# cat /etc/os-release
NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=2605.6.0
VERSION_ID=2605.6.0
BUILD_ID=2020-09-28-2140
PRETTY_NAME="Flatcar Container Linux by Kinvolk 2605.6.0 (Oklo)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar-linux.org/"
BUG_REPORT_URL="https://issues.flatcar-linux.org"
FLATCAR_BOARD="amd64-usr"

journalctl --boot -u docker
-- Logs begin at Tue 2020-10-06 15:49:25 UTC, end at Tue 2020-10-06 17:44:38 UTC. --
Oct 06 17:38:09 mantienne systemd[1]: Starting Docker Application Container Engine...
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.644756869Z" level=info msg="Starting up"
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.699907778Z" level=info msg="libcontainerd: started new containerd process" pid=738
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.701025860Z" level=info msg="parsed scheme: \"unix\"" module=grpc
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.701144665Z" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.701262568Z" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///var/run/docker/containerd/containerd.sock 0  }] }" modul>
Oct 06 17:38:09 mantienne dockerd[682]: time="2020-10-06T17:38:09.701387933Z" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
Oct 06 17:38:09 mantienne dockerd[738]: time="2020-10-06T17:38:09.828401077Z" level=info msg="starting containerd" revision=40779f9760e207feb7ff24cf21236bf5e63b2b17 version=1.3.7
...
Oct 06 17:39:49 mantienne dockerd[682]: time="2020-10-06T17:39:42.841452604Z" level=error msg="Failed to start container 4ed4990aae075c3f833eb6e333c6ab36baee711ba44717a7489cf2ccb20a4a39: OCI runtime create failed> ...
...
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:15.945040333Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:15.951512208Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:15.951589580Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:15.951642001Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:15.951676107Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:16.012045326Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:16.015254719Z" level=error msg="stream copy error: reading from a closed fifo"
Oct 06 17:40:16 mantienne dockerd[682]: time="2020-10-06T17:40:16.019335322Z" level=error msg="stream copy error: reading from a closed fifo"
...
Oct 06 17:40:21 mantienne dockerd[682]: time="2020-10-06T17:40:21.834153935Z" level=info msg="Daemon has completed initialization"
Oct 06 17:40:21 mantienne systemd[1]: Started Docker Application Container Engine.
Oct 06 17:40:21 mantienne dockerd[682]: time="2020-10-06T17:40:21.890268502Z" level=info msg="API listen on [::]:2376"
Oct 06 17:40:21 mantienne dockerd[682]: time="2020-10-06T17:40:21.890467617Z" level=info msg="API listen on /var/run/docker.sock"

Do you have some clue about this ?

Seems like a race condition because the containerd service unit treats the services as ready as soon as it runs but it should only be ready if it is actually able to accept requests on the socket. It needs to be changed to Type=notify but this requires containerd support for a sd_notify call after it set up the socket. It seems that it is supported and we can try to use it: https://github.com/containerd/containerd/blob/master/containerd.service

Hi @photos, thanks for the quick answer :-)
Here is the docker.service unit content :
# systemctl cat docker.service
# /run/systemd/system/docker.service
[Unit]
Requires=torcx.target
After=torcx.target
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=containerd.service docker.socket network-online.target
Wants=network-online.target
Requires=containerd.service docker.socket

[Service]
EnvironmentFile=/run/metadata/torcx
Environment=TORCX_IMAGEDIR=/docker
Type=notify
EnvironmentFile=-/run/flannel/flannel_docker_opts.env
Environment=DOCKER_SELINUX=--selinux-enabled=true

# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/env PATH=${TORCX_BINDIR}:${PATH} ${TORCX_BINDIR}/dockerd --host=fd:// --containerd=/var/run/docker/libcontainerd/docker-containerd.sock $DOCKER_SELINUX $DOCKER_OPTS $DOCKER_CGROUPS $DOCKER_OPT_>
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/docker.service.d/10-machine.conf
[Service]
Environment=TMPDIR=/var/tmp
ExecStart=
ExecStart=/usr/lib/coreos/dockerd  --host=unix:///var/run/docker.sock --host=tcp://<IP_ADDRESS>:2376 --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --la>
Environment=

Why does docker.service runs two services : dockerd and containerd ?

Here is the tree of processes in docker.service:
* docker.service - Docker Application Container Engine
     Loaded: loaded (/run/systemd/system/docker.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/docker.service.d
             `-10-machine.conf
     Active: active (running) since Tue 2020-10-06 17:40:21 UTC; 13h ago
       Docs: http://docs.docker.com
   Main PID: 682 (dockerd)
      Tasks: 417
     Memory: 276.5M
     CGroup: /system.slice/docker.service
             |- 682 /run/torcx/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://<IP_ADDRESS>:2376 --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.>
             |- 738 containerd --config /var/run/docker/containerd/containerd.toml --log-level info
...
             |-3327 containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/73b4f2747a169d9c5f5c122f0e93997858711f4989be413e5fb78218397198f8 -address /var/ru>
             |-3362 /run/torcx/bin/docker-proxy -proto tcp -host-ip <IP_ADDRESS> -host-port 443 -container-ip <IP_ADDRESS> -container-port 443
             |-5687 containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/b020549628ed66f4bd882a913e4230ace964be0ab1bad529a054e92a347ddc64 -address /var/ru>
...
             `-5704 containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/6fcba295ec14069b8c2c495a2d383a78b81c690845cc43ac42338574708027e2 -address /var/ru>

Action to be done here: We are still using Type=simple and should migrate to Type=notify in https://github.com/flatcar-linux/coreos-overlay/blob/main/app-emulation/containerd/files/containerd.service#L6

Action to be done here: We are still using Type=simple and should migrate to Type=notify in https://github.com/flatcar-linux/coreos-overlay/blob/main/app-emulation/containerd/files/containerd.service#L6

Done @ https://github.com/flatcar/scripts/pull/866 @pothos


patchValue for form builder with file picker

Tried to patch initial value to form builder. every other form fields pick the initial value but not file picker. How can I solve that ?

Hi!
Can provide this thinks please?
Environment
Package version:

Flutter doctor

Code sample

Description
Expected behavior:
Current behavior:
Steps to reproduce

This
Than that
Then


Let legacy ws clients know about invalid data frames

Starting with this PR, we will let legacy WS clients know when they send data frames (e.g., binary instead of text data frames) that are not supported by the protocol instead of simply ignoring them.
Description
While working on unifying all WebSocket implementations, I noticed that our implementation of the legacy WS protocol currently silently ignores unsupported data frames (i.e., binary data frames). So, I rechecked the protocol specs. They say only "stringified" JSON messages are allowed. That's the same formulation used in the newer WS protocol, where it is used to indicate that only text data frames are supported (related discussion: https://github.com/enisdenjo/graphql-ws/issues/409).
Starting with this PR, we report the use of unsupported data frames to clients (before, we ignored them). This should not cause any disruption to clients since they usually operate in text or binary mode. If they operate in text mode, everything will keep working. If they operate in binary mode, they never worked but will receive an error message now.
Close code 1002 was chosen because that code is also used in the reference implementation of the legacy protocol to signal protocol violations. The generally vague specs don't stipulate any more specific code for this scenario.
Types of Changes

[ ] Core
[ ] Bugfix
[ ] New feature
[x] Enhancement/optimization
[ ] Documentation

Checklist

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Summary by Sourcery
Enhance the legacy WebSocket protocol implementation to notify clients when unsupported binary data frames are sent, closing the connection with a specific error code and reason. Update tests to reflect this change and add documentation to inform users of the new behavior.
Enhancements:

Notify legacy WebSocket clients of unsupported binary data frames by closing the connection with code 1002 and a specific reason.

Documentation:

Add a release note indicating that legacy graphql-ws clients will now receive an error for binary data frames instead of them being ignored.

Tests:

Update tests to verify that non-text WebSocket messages result in a connection closure with the appropriate close code and reason.

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

Starting with this release, clients using the legacy graphql-ws subprotocol will receive an error when they try to send binary data frames.
Before, binary data frames were silently ignored.
While vagugely defined in the protocol, the legacy graphql-ws subprotocol is generally understood to only support text data frames.
Here's the tweet text:
🆕 Release (next) is out! Thanks to @NucleonJohn for the PR 👏

Get it here 👉 https://strawberry.rocks/release/(next)

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

Starting with this release, clients using the legacy graphql-ws subprotocol will receive an error when they try to send binary data frames.
Before, binary data frames were silently ignored.
While vagugely defined in the protocol, the legacy graphql-ws subprotocol is generally understood to only support text data frames.
Here's the tweet text:
🆕 Release (next) is out! Thanks to @NucleonJohn for the PR 👏

Get it here 👉 https://strawberry.rocks/release/(next)


pyamf don't work with python 2.7.6 (ubuntu 14.04)

there is content_type and httplib problems, the first was solved withing ./remoting/client/init.py, and the latter with python libs duplication and hacking (urllib2 and httplib).
Is anyone aware of that? Recently I had to work with amf3 and had a tough time figuring all out. I'll be happy to help test and try to solve all issues in pyamf if there is room for that.

Can you post the patch that you applied and I can take a deeper look. There is some pretty decent test coverage for the remoting client and the tests are currently passing for python 2.7 on Travis (https://travis-ci.org/hydralabs/pyamf/jobs/47837047).

Travis CI is still on Precise - http://docs.travis-ci.com/user/ci-environment/#CI-environment-OS I don't have access to Trusty. Without further info, I can't diagnose further (even a simple stacktrace would be useful).
Closing until OP responds.


Investigate the viability of ESLint compatible rules

It'd be rad if we could have rules that are interchangeable with ESLint.
If we do it right we could be able to share many style central rules i.e. like trailing commas, white space after commas etc..
These shouldn't require any Sass specific logic depending on the level of AST abstraction within the ESLint API.

From a cursory look, we could apply some the no-comma-dangle rule to Sass data types with a very thin adapter layer.

:+1:

If this were implemented, wouldn't sass-lint also get a performance bump from doing only a single traversal of the AST, and having rules attached themselves to specific nodes?

@benthemonkey the original intent was to lint in a single pass. In order to get 1.0 out we took a more naive approach for the sake of getting things done.
Considering the pace the rules have been implemented, I'm not convinced this issue in it's original intent, makes sense anymore.
I expect for v2 we'll adopt an architecture similar to eslint, which allow single pass linting for most (all?) rules. It would be at this point we'd implement pluggable rules.

This makes sense to me a single pass would be pretty good. Hopefully as you say with the speed the rules have been added we shouldn't be far off of parity with scss-lint (and then some!) so work on v2.0 could happen fairly soon.


I am facing issue on libgthread

This is the error i am getting,
Press Ctrl+C to exit
Already up-to-date
Update succeeded.
[System ARGV] ['Fooocus/entry_with_update.py', '--always-high-vram']
Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0]
Fooocus version: 2.3.0
Version mismatch for Pillow: Installed version 10.2.0 does not meet requirement Pillow==9.2.0
Installing requirements
Traceback (most recent call last):
File "/home/studio-lab-user/Fooocus-Sagemaker-Studio-Lab/Fooocus/entry_with_update.py", line 46, in
from launch import *
File "/home/studio-lab-user/Fooocus-Sagemaker-Studio-Lab/Fooocus/launch.py", line 83, in
from modules import config
File "/home/studio-lab-user/Fooocus-Sagemaker-Studio-Lab/Fooocus/modules/config.py", line 8, in
import modules.sdxl_styles
File "/home/studio-lab-user/Fooocus-Sagemaker-Studio-Lab/Fooocus/modules/sdxl_styles.py", line 7, in
from modules.util import get_files_from_folder
File "/home/studio-lab-user/Fooocus-Sagemaker-Studio-Lab/Fooocus/modules/util.py", line 8, in
import cv2
File "/home/studio-lab-user/.conda/envs/fooocus/lib/python3.10/site-packages/cv2/init.py", line 181, in
bootstrap()
File "/home/studio-lab-user/.conda/envs/fooocus/lib/python3.10/site-packages/cv2/init.py", line 153, in bootstrap
native_module = importlib.import_module("cv2")
File "/home/studio-lab-user/.conda/envs/fooocus/lib/python3.10/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: libgthread-2.0.so.0: cannot open shared object file: No such file or directory

Hi, please try using the updated model-management notebook to delete the existing installation by running the last code block and then reinstall Foocus by running start.sh
I fixed an issue where conda was failing to install glib, so a fresh install using the new script should work.

Hi, please try using the updated model-management notebook to delete the existing installation by running the last code block and then reinstall Foocus by running start.sh
I fixed an issue where conda was failing to install glib, so a fresh install using the new script should work.

Again facing the same issue i reinstalled the model also i am getting the same kind of error

In line 4 of your output, it says "Could not find conda environment: fooocus", which means the fooocus conda environment doesn't exist. This is what's causing the error.
I was not able to reproduce this on a clean install, so I'm not sure what happened on your instance that caused it. I suggest clearing out the /tmp folder and deleting ~/.conda/envs/fooocus if it exists, downloading the latest start.sh script and trying again with a clean install.

I created the another account using different E mail id that instance was working fine fine no issue. only facing the issue to the particular account getting an "error'' i clear the temp file also but  again getting same error how to fully reset the account any idea!    ?

A quick way to delete all data and conda environments is to open a terminal and run:
rm -rf ~/*
rm -rf ~/.conda/envs/*
Restarting the instance will re-create the default and studiolab conda environments. What I usually do is just delete conda envrionments I don't need from the file browser, so I don't need to restart my runtime.

rm -rf ~/*
rm -rf ~/.conda/envs/*
This command working fine issue resolved. once clear the conda environment  👌


Hyundai CAN: check traction control enabled

https://connect.comma.ai/75d3263b7dd5268b/1712813960756/1712814119564

@sunnyhaibin interested in finding this for CAN FD?


EnumValueConverter and AndWhere

Migrated From https://bitbucket.org/Readify/neo4jclient/issue/82/enumvalueconverter-and-andwhere
Michael Dolinsky created an issue 2013-04-08
EnumValueConverter serializes enum properties using their names.
But when we query some nodes using property of enum type we can't use: AndWhere<NodeClass>(node => node.EnumProperty != Enum.EnumValue)
What we should do is... AndWhere<NodeClass>(node => node.EnumProperty.ToString() != Enum.EnumValue.ToString())
Michael Dolinsky
The same problem exists with DateTimeOffset types, they are also not being converted as part of Where clause. So the query text contain date time in the following format “03/09/2013 19:24:07 +03:00” instead of "2013-04-08T13:41:03.3348842+00:00".
@tathamoddie
There's now a failing test case in the issue-82 branch so that we can start fixing the problem.
@mavadat
In C# the following expressions are identical. What do we expect to happen in Neo4jClient for each?
Expression<Func<SomeEnum,bool>> expA =  myParam => myParam == SomeEnum.Def;
Expression<Func<SomeEnum,bool>> expB =  myParam => (int) myParam == (int) SomeEnum.Def;
How about the following expression:
Expression<Func<Weekday, bool>> expression = day => ((int) day) + 1) == (int) Weekday.Friday
It's a matter of enum semantics. Treating enums as strings [current behaviour] doesn't nicely match with .NET enum semantics which are essentially integral values with no boundary checks.

Will there be a fix for this issue? What's the best way to handle it? The .ToString()-Workaround might work, but treating enums as strings blows up database size with unnecessary string values? It might also have negative impact on query performance. And hopefully nobody will ever rename an enum, normally no problem in C#. Any advice?

Any updates on this ?


Aker email accounts not being sent notifications for tasks

dev context:
A PCS person has an email property which is the preferred email and not necessarily the EQ mail. The fusion Notifications api specifies personIdentifier but after digging into the code its either email or azure oid.
By resolving this email property from PCS we can send an email to the preferred email instead of the EQ mail.

This needs a rework, short summary.
The fusion notifications api is capable of sending emails out of Equinor. But the email must be registered on their account in fusion. Today this is only possible in the contract personnel application. This is not feasible for Castberg fix.
Implementation flow

If user is Equinor and have EQ preferred mail in pcs. No problem✅ User gets email and notification
User is Equinor and preferred email is aker in pcs and user has 365 acc in equinor. User gets email for both EQ and aker. And fusion notification. ✅
User is Equinor and preferred email is aker in pcs but user does not have 365 acc in EQ. User gets email in ext email and notification in fusion.

The Fusion mail endpoint doesnt support adaptive cards. I made some custom html that im sending to the server


Update Issue is not working

I've tried to update a issue with a custom field, following the tutorial at Readme and i got no results. The same ocurr when i tried to add a Journal.
I believe that issueManager().updateIssue() is calling RedmineJSONBuilder.toSimpleJSON with a wrong writter perhaps?

cannot proceed on this request without code sample and stacktrace or specific bug info.
feel free to reopen once that is provided, also please provide a patch/ Pull Requests with a fix and proper tests. I would be happy to review and merge that


Patch mkimage-yum.sh to work with Amazon Linux (2014.09)

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:lkinley/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ok, done... do I need to create a new pull request?

@lkinley no you don't! You just updated the current pull request :)
@jfrazelle do you think we should update the text to say something like "This will update the existing pull request, so no need to open a new one" ?
Ping @tianon :)

i will do that ;)

hmmm seems sane to me, @tianon?

Copying the file from the host is less than ideal, but I don't see a better way, so
LGTM :+1:


Attention seems to focus on the '\n' token

Hi,
I have implemented the attention rollout method to quantify the information flow through the openvla model. Interestingly, when I plot the attention rollout from the action tokens to the text input, I see that most attention is on the newline token '\n'. Below is an example of the attention with the input prompt: "In: What action should the robot take to pick up the chips bag? \n Out:".
Do you know why the method seems to attend most to the token '\n'?

Interesting visualization!
OpenVLA uses an auto-regressive transformer, so the /n token can attend to all previous tokens, so it's well possible that the model concentrates all the relevant information from the previous tokens in that last token. So not necessarily an issue, but definitely interesting! thanks for sharing!

Thanks for your input. Isn't it odd that the action output primarily attends to the newline character and not the "pick" or "bag" tokens? There's nothing special about the newline token, right?


Possible Bug at PdfDocument.Render()

In the task #79 and #114 is explained how the PdfRenderFlag CorrectFromDpi should be used, to recalculate from points (Pdf maesurement) into pixel. Which looks like this inside the method PdfDocument.Render:
           if ((flags & PdfRenderFlags.CorrectFromDpi) != 0)             {                 width = width * (int)dpiX / 72;                 height = height * (int)dpiY / 72;             }
Intersting enough is, that if i use the CorrectFromDpi PdfRenderFlag, the resulting image will be in the wrong size.
So a dinA4 pdf file using these settings (I wrote here only the numbers for width and height, which came from the pdfDocument):
Image image = document.Render(pageNumber, 595, 842, 600, 600,PdfRenderFlags.CorrectFromDpi)
resulted in an image with 4800x6600 pixels and 600dpi. This is the equivalent of 8x11 inches. But a dina4 page should have 8.3x11.7 inches.
So i experimented with increasing the file length by some points, to find out that this increase does not change anything. Of cause a little bit of accuracy we loose converting points into pixel in the method PdfDocument.Render. But it shouldnt be that much.
If i Use no Render Flags and execute the method with my own recalculation:
Image image = document.Render(i,  (int)(595*600/72),  (int)(842*600/72), 600,  600, PdfRenderFlags.None)
it works perfekt.
I couldnt figure out what is happening there, that the calculations are this far off. Maybe its worth looking for?
Greetings,
Manju

It's because it's computing on integers in the wrong order. Your computation is far more precise, because it converts the result to int after all the maths. If I take dpiX as 600, in the code way I get (int)dpiX / 72 =>8, therefore Width = 595 * 8 => 4760. In fact, if you compute it your way, it's Width = 595 * 8.333, which makes 4958. Look at your code, and you'll see, you're having the cast to int at the very end of the maths, not like in the original code. There you have your difference.


merge from konsum-frontend-svelte,template-svelte-app

package.json

chore(deps): add ^10.15.23 remove ^10.15.22 (devDependencies.npm-pkgbuild)

:tada: This PR is included in version 1.35.0 :tada:
The release is available on:

npm package (@latest dist-tag)
v1.35.0
GitHub release

Your semantic-release bot :package::rocket:


Deleted duplicate action results in WebapiCompatShim

@rynowak

:watch: Deleted too much! Just the action result types should go. All of the functionality needs to stay

Updated.

:watch:

Updated.

:shipit:


Unable to run ./imglab --cluster.

Unable to run ./imglab --cluster 8 ../data/OutputDir/training.xml
ERROR: unable to open ../data/OutputDir/training.xml for reading.
but path to training.xml is valid, I can run for example
./imglab --stats ../data/OutputDir/training.xml
Update:
./imglab --cluster 8 training.xml works, if I place training.xml in the same folder near imglab, also it work if I use full path to training.xml, so for some reason relative path is not working.

Yeah, that's a problem.  I just pushed the fix to github.  Thanks for finding this :)


Documention for build_with_nuitka with pbr

setup(build_with_nuitka=True,pbr=True) does not work, however it looks like setup(pbr=True,build_with_nuitka=True) does work, at least for a few I have tried.

It looks like pbr causes problems, because it builds the list of packages, and then returns them in an unusual order, and nuitka distutils plugin only consumes the first one.
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.contrib' from 'requests_mock/contrib'. (Module is exact match of 'requests_mock.contrib' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.contrib._pytest_plugin' from 'requests_mock/contrib/_pytest_plugin.py'. (Module is package content of 'requests_mock.contrib' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.contrib.fixture' from 'requests_mock/contrib/fixture.py'. (Module is package content of 'requests_mock.contrib' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock' from 'requests_mock'. (Module is exact match of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.adapter' from 'requests_mock/adapter.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.compat' from 'requests_mock/compat.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:WARNING:Recursed to package 'contrib' at '/home/abuild/rpmbuild/BUILD/requests-mock-1.7.0/build/lib/requests_mock/contrib' twice.
[   63s] Nuitka:WARNING:Recursed to module '_pytest_plugin' at '/home/abuild/rpmbuild/BUILD/requests-mock-1.7.0/build/lib/requests_mock/contrib/_pytest_plugin.py' twice.
[   63s] Nuitka:WARNING:Recursed to module 'fixture' at '/home/abuild/rpmbuild/BUILD/requests-mock-1.7.0/build/lib/requests_mock/contrib/fixture.py' twice.
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.exceptions' from 'requests_mock/exceptions.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.mocker' from 'requests_mock/mocker.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.request' from 'requests_mock/request.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)
[   63s] Nuitka:INFO:Recurse to import 'requests_mock.response' from 'requests_mock/response.py'. (Module is package content of 'requests_mock' instructed by user to recurse to.)

After @tommyli3318 changes for 0.6.6 this is considered resolved. There is no main package anymore, and the order of packages provided does not matter anymore, or at least it should not.

The problem as mentioned in the first post is with build_with_nuitka and pbr.  Given the importance of pbr, this really need some dedicated testing to ensure it is fixed, and ideally even a dedicated set of tests.

I was thinking this was only about the order of packages as provided to Nuitka, this is now irrelevant, I am not sure, what the problem could be there. Can you point us to a package that uses pbr and fails to work?

@jayvdb Do you have such an example package using pbr so we can reproduce it?

Closing for lack of feedback.


"Missing Xref" and "Rename Failed: Memory storage not found for global variable"

Describe the bug
Setting a certain type to group of bytes and then trying to rename that group to a usable name results in the error:
Rename Failed: Memory storage not found for global variable

To Reproduce

Import the attached Ghidra database
Go to the function "DisplayMenu"
Early in the (big) function is a switch case with "MENU_TXP". Go there.
You will see 'pcVar6 = "LOW";'. Double click on the LOW string to see it in the disassembly window
On the bytes of LOW, notice how it has no Xref. Now change its type (press T) to char[3][5]. Accept to clear the conflict.
The variable pcVar6 will now show 'pcVar6 = (char *)CHAR_ARRAY_ARRAY_0000de61;'
The new variable name cannot be renamed and gives the error mentioned above

It can be noticed that even though the group of bytes has been labelled with a variable, the group of bytes themselves do not have an XREF that is access by the function.
Expected behavior
I would expect to be able to rename the variable and to see an Xref on the associated bytes.
Screenshots
Attachments
uv-k5-v2.01.27.main.zip
Environment (please complete the following information):

OS: Windows 10 Enterprise, up to date with patches/feature updates
Java Version: openjdk version "17.0.3" 2022-04-19
Ghidra Version: 10.3.2
Ghidra Origin: Release binaries from github.

Additional context
I'm guessing that the rename failure is due to the lack of Xref but wanted to show the rename problem just in case it's unrelated to xref (both cases are a problem).

The problem can also be reproduced in other switch cases. Whenever you find the following sequence:
pcVar6 = "blabla";
SubStringOffset = _gSubMenuSelection << SOMENUMBER;
it means that there's an array of strings at the address of "blabla". The length of each array entry is "1 << SOMENUMBER".


Incorrect format string in strftime

Describe the bug
It appears that line
https://github.com/NeuralEnsemble/python-neo/blob/8d5d1884378258dfd6fe9b7f878c79beffe5404a/neo/io/nixio.py#L633
uses the incorrect format string "%s" instead of "%S" (capital S is the only valid format string for output in seconds as far as I can see),
which triggers the error
  File "C:\Users\tn41\anaconda3\lib\site-packages\neo\io\nixio.py", line 633, in write_block
    nix_rec_dt = int(block.rec_datetime.strftime("%s"))
ValueError: Invalid format string

when using write_block() of nixio.
To fix, just replace with the correct format string:
nix_rec_dt = int(block.rec_datetime.strftime("%S"))
Environment:

OS: Windows
Python version 3.9.13
Neo version 0.12.0 (but the error is present in the current master on github)
NumPy version 1.12.5

Additional context
Please fix; I can fork the repo and make a pull request if you prefer but it seems overkill for such a minimal change.

Hi @tnowotny,
thanks for reporting this issue. In fact this a limitation of the formatting options available on Windows. I implemented a fix here. Can you confirm this solves the issue?

Hi @JuliaSprenger , I can confirm the new version with timestamp() appears to work for me. Thanks for the quick fix.