after setting 2560x1440, my monitor no worky

run  wlr-randr --dryrun can see 2560x1440@60Hz
$ wlr-randr --dryrun
HDMI-A-1 "Unknown PE24QA2 0x00000001 (HDMI-A-1)"
  Physical size: 530x300 mm
  Enabled: yes
  Modes:
    ...
    1920x1080 px, 50.000000 Hz
    1920x1080 px, 59.939999 Hz
    1920x1080 px, 60.000000 Hz (current)
    2560x1440 px, 75.000999 Hz
    2560x1440 px, 60.000000 Hz (preferred)
  Position: 0,0
  Transform: normal
  Scale: 1.000000

I run the command wlr-randr --output HDMI-A-1 --mode 2560x1440@60Hz or set monitor=HDMI-A-1,2560x1440@60,0x0,1
the monitor does not work
I can run the command wlr-randr --output HDMI-A-1 --mode 2560x1440@60Hz  in wayfire,
it work fine

this is my log file
log.txt

Two things:
Have you tried setting it BEFORE launching hyprland?
(If you enabled VFR), have you tried disabling it? And, since Hyprland forces adaptive sync on all monitors, does your monitor support that?

Two things:
Have you tried setting it BEFORE launching hyprland?
(If you enabled VFR), have you tried disabling (禁用) it? And, since Hyprland forces adaptive (自适应) sync (同步) on all monitors, does your monitor support that?
@vaxerski

I launching hyprland from tty, when I run the command wlr-randr --output HDMI-A-1 --mode 2560x1440@60Hz in tty. I get " failed to connect to display.
I only have one monitor.
I dont now VFR, can you tell me how to disable it.

is this?

VFR is disabled by default, (it's a hyprland option) so if you didnt enable it, it's disabled.

I launching hyprland from tty, when I run the command wlr-randr --output HDMI-A-1 --mode 2560x1440@60Hz in tty. I get " failed to connect to display.

Set the resolution in your hyprland config, then launch it. Do not use wlr-randr.

Set the resolution in your hyprland config, then launch it. Do not use wlr-randr.

@vaxerski
I have already set up, but my monitor no worky
❯ cat .config/hypr/hyprland.conf | grep HDMI
monitor=HDMI-A-1,2560x1440@60,0x0,2

Changed a dp line, and it's fine


ci: add more tests

:notebook: Overview
Adds more tests

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

5 of 5 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+4.1%) to 47.151%

Totals

Change from base Build<PHONE_NUMBER>:
4.1%

Covered Lines:
536

Relevant Lines:
1058

💛  - Coveralls


Clicking elsewhere doesn't always make a context menu disappear

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.74.0-insider
OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

Make some context menu appear: from a buffer, the left sidebar, the status bar, the workspace-search textbox, the title bar (not the system menu in the area of the app icon).
Click on the title bar anywhere where the centered text is or on the free space to the left or right of it. This doesn't work to hide the context menu, as one would expect (not even the one shown by clicking in the area). Strangely, clicking further to the left or right towards where I described works (e.g., on the menu bar texts, but not on the app icon).

This is a known issue and limitation in electron. These click events are taken by the OS (as they control dragging the window)


Stop loss bug

Using the last pull version.
Errors occurs during stop loss try
2024-09-14 15:03:36 - BybitBaseStrategy - ERROR - [BIGTIMEUSDT] Error during stop-loss attempt for short position: 'LinearGridBaseFutures' object has no attribute 'create_limit_order_bybit'
2024-09-14 14:45:59 - BybitBaseStrategy - ERROR - [COTIUSDT] Error during stop-loss attempt for short position: 'LinearGridBaseFutures' object has no attribute 'create_limit_order_bybit'

And another one I am not sure happening why:
2024-09-14 15:04:41 - BybitBaseStrategy - ERROR - Exception caught in should_replace_grid_updated_buffer_min_outerpricedist_v2: unsupported operand type(s) for -: 'NoneType' and 'float'
Traceback (most recent call last):
  File "/root/directionalscalper2/directionalscalper/core/strategies/bybit/bybit_strategy.py", line 12850, in should_replace_grid_updated_buffer_min_outerpricedist_v2
    price_change_pct_long = abs(current_price - last_reissue_price_long) / last_reissue_price_long * 100.0
                                ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~

Should be resolved but leaving this open for a bit just in case


ServiceContext->UsePlatformServices results in a blank baseserviceURL in $this->context

Edited:
I believe I have found the source of the problem. Please see comment below for what I think is the issue.
context:
I'm not sure if this is me doing something wrong or if the SDK is not working. However I am trying to implement a disconnect from QBO button in the app that I'm working on and after setting up the following
// my other code that contains my keys and stuff above ^^^

$dataServiceConfig = [
    'auth_mode' => 'oauth1',
    'consumerKey' => OAUTH_CONSUMER_KEY,
    'consumerSecret' => OAUTH_CONSUMER_SECRET,
    'accessTokenKey' => $authToken,
    'accessTokenSecret' => $authTokenSecret,
    'QBORealmID' => $realmId,
    'baseUrl' => "https://sandbox-quickbooks.api.intuit.com/"
];

$serviceContext = ServiceContext::ConfigureFromPassedArray($dataServiceConfig);

$platformService = new PlatformService($serviceContext);

// everything from this point on fails and outputs NULL
$Respxml = $platformService->CurrentUser();
var_dump($Respxml);

$Respxml = $platformService->Disconnect();
var_dump($Respxml);

I'm not sure if this is because what i've done and how i've initialized the instance of PlatformService is incorrect or if the PlatformService class itself is broken. so i looked into the logs to see what was happening and this is what i got out of them
RESPONSE URI FOR SEQUENCE ID 01497
==================================
v1/Connection/Disconnect

RESPONSE HEADERS
================

RESPONSE BODY
=============

==================================
v1/user/current

RESPONSE HEADERS
================

RESPONSE BODY
=============

a typical response looks like this for me
RESPONSE URI FOR SEQUENCE ID 01485
==================================
https://sandbox-quickbooks.api.intuit.com/v3/company/__ID_hidden__/query?minorversion=4

RESPONSE HEADERS
================
Server: nginx
Content-Type: application/xml;charset=UTF-8
... some other stuff i've decided to hide bla bla

RESPONSE BODY
=============
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>... the rest of the response goes here

the typical response has a DataService object initiated in this way
$dataServiceConfig = [
    'auth_mode' => 'oauth1',
    'consumerKey' => OAUTH_CONSUMER_KEY,
    'consumerSecret' => OAUTH_CONSUMER_SECRET,
    'accessTokenKey' => $authToken,
    'accessTokenSecret' => $authTokenSecret,
    'QBORealmID' => $realmId,
    'baseUrl' => "https://sandbox-quickbooks.api.intuit.com/"
];

$dataService = DataService::Configure($dataServiceConfig);

Thanks for the help!

 I have dug through the code of the SDK and i believe the source of the problem is in the ServiceContext class.
//...other code

    /**
     * Gets the base Uri for a QBO user.
     *
     * @return string Returns the base Uri endpoint for a user.
     */
    public function getBaseURL()
    {
        $this->IppConfiguration->Logger->RequestLog->Log(TraceLevel::Info, "Called GetBaseURL method.");
        try {
            if ($this->serviceType === CoreConstants::IntuitServicesTypeQBO) {
                $baseurl = $this->IppConfiguration->BaseUrl->Qbo . implode(CoreConstants::SLASH_CHAR, array(CoreConstants::VERSION)) . CoreConstants::SLASH_CHAR;
            }
            else {
                $baseurl = $this->IppConfiguration->BaseUrl->Ipp;
            }
        } catch (\Exception $e) {
            throw new \Exception("Base URL is not setup");
        }
        return $baseurl;
    }

    /**
     * Populates the values of the service context like service type and base url to Platform Services.
     */
    public function UsePlatformServices()
    {
        $this->serviceType = CoreConstants::IntuitServicesTypeIPP;
        $this->baseserviceURL = $this->getBaseURL();
    }

//... other code```

when i tried adding a var_dump($this->baseserviceURL) at the end of `public function UsePlatformServices()` it outputted a null which then results in a failed URL in the `GetResponse()` function of SyncRequestHandler class. and the problem seems to be t hat there's no action in the `getBaseURL()` function that handles `$this->serviceType == CoreConstants::IntuitServicesTypeIPP` Hope this helps someone out there figure out how to resolve this issue!

This is exactly the issue I just found as well
$this->serviceType = CoreConstants::IntuitServicesTypeIPP;
Which uses the IPP baseUrl, and that hasn't been set.
The Disconnect method fails, but also the Reconnect which makes it impossible to refresh auth tokens.

Yes.  This is a duplicate of issue #24.  It is a problem when configuration is done from an array rather than a file.
Temporary solution is to call
$serviceContext->IppConfiguration->BaseUrl->Ipp = "https://appcenter.intuit.com/api/";
after creating PlatformService but before trying to use it.

@all
I think there is some issue with the Platform service call. Let me take a look and see what the problem is.

I also had this issue, when calling  $platformService->Disconnect(); I was getting a false Boolean. I thought that I had the wrong endpoint for a while, @muggy8 fix worked for me thanks.

@ALL
This should be fixed on v3.2.6.
All Platform calls should work properly now.
Any issue, ping me.


disable interrupts during programming of the ICR

ICR programming should be not-interruptable to avoid corrupted values

bors r+

bors r+

bors r+


Detecting connection status doesn't seem to work

Prerequisites

[x] I am running the latest version
[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed

Expected Behavior

When running bleManager.isDeviceConnected(deviceId) I should be getting true/false.
When subscribed using bleManager.onDeviceDisconnected(device.id, callback) the callback should be called when device is disconnected.

Current Behavior

isDeviceConnected() is returning me the follwing response regardless if the device is connected or not {"_40": 0, "_55": null, "_65": 0, "_72": null}

callback is never called when device disconnects

Context
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions. Both JS and platform logs can be enabled via setLogLevel function call.

Library version: 2.0.0
Platform: Android.
Platform logs (logcat):
JS logs:
Contents of the package.json file:

  "dependencies": {
    "react": "16.11.0",
    "react-native": "0.62.2",
    "react-native-ble-plx": "^2.0.0",
    "react-native-push-notification": "^3.4.0"
  },
  "devDependencies": {
    "@babel/core": "^7.6.2",
    "@babel/runtime": "^7.6.2",
    "@react-native-community/eslint-config": "^1.0.0",
    "@types/jest": "^24.0.24",
    "@types/react-native": "^0.62.0",
    "@types/react-native-push-notification": "^3.0.9",
    "@types/react-test-renderer": "16.9.2",
    "@typescript-eslint/eslint-plugin": "^2.27.0",
    "@typescript-eslint/parser": "^2.27.0",
    "babel-jest": "^24.9.0",
    "eslint": "^6.5.1",
    "jest": "^24.9.0",
    "metro-react-native-babel-preset": "^0.58.0",
    "prettier": "^2.0.4",
    "react-test-renderer": "16.11.0",
    "typescript": "^3.8.3"
  },

Android version: 10
Phone: SM-G986B/DS (Galaxy S20+ 5G)

Hello. It seems that on I checked the documentation and found no answer you have missed the truth as you would see that
bleManager.isDeviceConnected() with partially filled arguments.
isConnected(): Promise<boolean>
Returns
Promise<boolean>: Promise which emits true if device is connected, and false otherwise.

Does return a Promise. And this is what you have printed.
As for bleManager.onDeviceDisconnected(device.id, callback) I cannot verify because you did not filled the logs in the report as the issue template asks you to do. Please add the missing info and maybe there is something I could do.
Best regards


Find command errors in SetPropertyFromCommand for property "freshconfig" on builder auto-win-msvc-64-opt-rustbuild

On an unrelated build: https://buildbot.rust-lang.org/builders/auto-win-msvc-64-opt-rustbuild/builds/3217
The """freshconfig""" key is set to the value """0 /usr/bin/find: paths must precede expression: ^ Usage: /usr/bin/find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]"""
Relevant source: https://github.com/rust-lang/rust-buildbot/blob/master/master/master.cfg#LC976
The find command is valid on my macOS machine here.
It caused the should_wipe function to return the wrong value, making the WORK_DIR directory to not be removed before git clean -d -f -f in the next step. No clue if it contributed to the build failure.

auto bots are on there way out, so closing.


geanticlinal, deprovincialize

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[d,g]

/trunk merge


Allow enabling compose compiler per target in multiplatform module

Consider a project with a single multiplatform module with a js target for frontend and a jvm target for backend. This module might want to only enable the compose gradle plugin, compose compiler, and compose dependencies for the JS target and completely leave out compose for the jvm target.
This is discussed in https://github.com/JetBrains/compose-multiplatform/issues/1568. But it seems that issue is being treated as a question and not an enhancement proposal. So here I am making the proposal that the Compose Multiplatform Gradle Plugin allows developers to toggle compose per Kotlin Multiplatform target within a single module.

Will this solution work for you? https://github.com/JetBrains/compose-multiplatform/pull/3722

Not sure that configuring it per source set is possible at all. The source sets can't be compiled independetly. All relevant source sets get "combined" to compile for a particular target, and if a target declares to apply the Compose plugin, it means it's applied to all code (involved source sets).
And as for gradle configurations, I'm not sure I understand how it can affect the logic to apply or not apply the plugin.
I guess we can only decide to apply or not based on the target type or target name.

Yes, those are 2 jvm targets with different names.
Sure, let's close it.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


BUG: Is _freq_domain_conv missing a conjugation?

It looks like https://github.com/scipy/scipy/blob/b5d8bab88af61d61de09641243848df63380a67f/scipy/signal/_signaltools.py#L508
is missing sp2.conj? Maybe I've missed where the conjugation happens, but it does look like it's missing.

Hi @aragilar, thank you for reporting. Can you provide a bit more context/information on why?

Looking at wikipedia, the definition of cross-correlation is

where the function f has been conjugated. If we may sp1 to g and sp2 to f (which I think is correct, but I could be totally wrong), then we'd expect to have sp2 conjugated. It's possible I've misunderstood something fundamental about how to do cross-correlation numerically with FFTs (or I've misunderstood what fftconvolve and correlate are supposed to be for), but it does seem like we need to conjugation sp2?

The Mathworld definition of convolution doesn't have conjugation, while the cross-correlation definition definition does.
In correlatein the same file you pointed to, there's this code, in which conjugation is done for cross-correlation:
    if method in ('fft', 'auto'):
        return convolve(in1, _reverse_and_conj(in2), mode, method)

so my guess is whoever wrote this knew what they were doing.

Sounds like we can close this then.

Sorry, I've been conflating cross-correlation and convolution (as I confused myself and thought the functions were implementing the former, not the latter). The convolution is fine, it's the correlation that I think is wrong. The way I've seen it expressed is IFFT(FFT(x1)*CONJ(FFT(x2))) (see

and eqns 2-5 of https://articles.adsabs.harvard.edu/pdf/1979AJ.....84.1511T, which is why I'm looking at this, I was trying to understand the numerical error in different implementations), but it appears correlate does IFFT(FFT(x1)*FFT(REVERSE(CONJ(x2)))), which I don't think is equivalent?

Both numpy.correlate and scipy.signal.correlate define their correlation with conjugation of the second operand (or argument); from numpy.correlate, for example:
Signature: np.correlate(a, v, mode='valid')
Docstring:
Cross-correlation of two 1-dimensional sequences.

This function computes the correlation as generally defined in signal
processing texts::

    c_{av}[k] = sum_n a[n+k] * conj(v[n])

with a and v sequences being zero-padded where necessary and conj being
the conjugate.

The definitions I found (Wikipedia, dsprelated.com have conjugation on the first operand.  These definitions are not equivalent, being the complex conjugate of each other.  I don't know if this is just convention, with some books defining it one way, and some the other.
The reversing is odd; that seems to contradict the Wikipedia page you cited and also this development on dsprelated.com, but from another dsprelated.com page it looks like conjugation and reversal are related in Fourier transforms.


[Do Not Merge] Remove deprecated Google BigQuery sample

Pending documentation updates

[ ] Update documentation

Pull request should not have been sent.  Not ready for this deprecation.  Re-open at a later date.


[Skip CI] RAC-5200 restore back OVA mem size from 1G to 4G

Why skip CI
current PR Gate won't involve the packer build step
Why this change
Originally modified with this PR: https://github.com/RackHD/RackHD/commit/51121591a200c78c66f98075143cc65677685967
But accidentally,  it was overwritten with this PR: https://github.com/RackHD/RackHD/commit/5ba383d4bce6695ef1767d6b7fd612c961ddea54
@keedya  @iceiilin @anhou @PengTian0

:+1:


Webpack throwing config validation error

Here's (most of) my webpack configuration:

Here's the issue I'm experiencing:

The issue, to my knowledge, seems to reside in the .extract function in the rules configuration.

{
   loader: 'css-loader',
-   query: {...}
+   options: { importLoaders: 2 , sourceMap: true, minimize: !__DEV__ }
}
{
   loader: 'sass-loader',
   options: {
     includePaths: '...'
+   sourceMap: __DEV___
   },
-   query: {
-     sourceMap: __DEV__
-  }
}

How does POSTCSS_OPTIONS look like ?

Thanks for those changes!

These are my POSTCSS_OPTIONS.

cssnano is used by css-loader internally when you set minimize: true, I think you can even pass these options (POSTCSS_OPTIONS) to ['css-loader'].minimize directly =>
{ loader: 'css-loader', options: {...options, minimze: !__DEV__ ? POSTCSS_OPTIONS : false } }

Anyways 😛 , does it build now ?

Awesome, removed postcss-loader and it built successfully. Thank you so much. 😄


Fix for four dir rotation error

About the PR

I'm working on #27510 and noticed that [ERRO] system.mouse_rotator: User localhost@JoeGenero (057c06c0-0b64-499c-95d2-0e84823a6a1a) tried setting 4-dir rotation directly without a valid mouse rotator component attached! gets thrown occasionally when I trigger combat mode and attack with insane lag, I fixed it by moving the entity dirtying to the lines after the comp gets added or removed to the entity
This unfortunately does not solve the issues I'm working towards, but it should get rid of the error in Grafana since it no longer shows up locally...
Changelog

not player facing so nuh

unrelated test fail...


[Sample] Add Dynamic Entity Layer

Description
Implementation of the add-dynamic-entity-layer sample following design documentation and test app.

Slider max value adjusted to 5 instead of 16 as the observation data is limited to 5 minutes
Link to documentation in additional-information to be updated  when available
Metadata checks passed locally

Checklist:

[ ] Set target branch to main (current release) or v.next (next release)
[ ] Request a reviewer
[ ] Assign a reviewer
[ ] Tag reviewer in comment

Assigning to @jenmerritt for a first review please.

I've applied all of the above suggestions @jenmerritt, sample is ready for another look. The metadata checks will fail until the changes in #777 are merged but I have tested locally.

Comments updated @jenmerritt, thanks.


Fixing broken README logo

The README logo was broken when it was moved to the docs folder in my previous pull request.

This is why I have trust issues


fix(837): Updated the demos to include the new submit type

Also updated the package.json to include a command for running the react demo.
And updated the react-components to actually have an option for submit.
I have no idea how it was working in the Storybook prior to this.

:tada: This PR is included in version 4.0.0-alpha.44 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.98 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.16 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-alpha.6 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


proposal: arbitrary-radix integer literals

I've brought up this idea several times before informally. I'm filing this issue now for the formal documentation trail.
Currently, Go permits octal, decimal, and hexadecimal integer literals. There's a pending proposal for binary integer literals (#19308) which has wide support.
Proposal:
This is a fully backward-compatible proposal for arbitrary-radix integer literals. We change the integer literal syntax to the following:

int_lit = decimal_lit  | octal_lit | radix_lit .
decimal_lit = ( "1" … "9" ) { decimal_digit } .
octal_lit = "0" { octal_digit } .
radix_lit = radix ( "x" | "X" ) radix_digit { radix_digit } .
radix = decimal_lit .

with

radix_digit = "0" … "9" | "A" … "Z" | "a" … "z" .

representing the digit values 0 to 35 (for a maximum radix of 36). The radix must be a decimal literal between 0 and 36, expressing the radix; with the radix value 0 having the same meaning as 16, and the value 1 being invalid.
Examples:
0x10   // same as 16x10 or 16
2x1001 // binary integer literal, same as 9
3x010  // ternary integer literal, same as 3
8x066  // octal integer literal, same as octal 066 or 54
36xz   // integer literal in base 36, value is 35

Discussion:
The beauty of this approach is that it permits arbitrary radix notation, thus removing any future need to expand this again, remove the need for the extra notation for hexadecimal numbers because they are just part of this notation, and at the same time it's fully backward-compatible. The commonly accepted notation for binary integer literals and the respective notation here have the same length and the proposed notation here seems just as intuitive (e.g., 0b1001100 == 2x1001100).
We could go a step further and remove octal literals from the language since they are also easily expressed with this notation, but that's a step that would not be backward-compatible. One way to make that happen w/o introducing bugs would be to disallow non-zero decimal numbers that start with a 0; octal numbers in existing code would then lead to a compiler error and could be fixed. It would also be trivial to have them fixed automatically with a simple tool. Finally, removing octals would eliminate another (albeit mostly academic issue) with them; see #28253. If octals were not supported anymore, one could condense the integer literal syntax to:

int_lit = decimal_digit { decimal_digit } [ ( "x" | "X" ) radix_digit { radix_digit } ] .

Implementation:
The implementation is straight-forward. It would likely slightly simplify some of the scanning code for numeric literals because with this proposals now all such literals simply start with a decimal_lit always. If that value is zero, or between 2 and 36, a subsequent 'x' indicates the actual literal value in that radix. The respective number conversion routines are trivial and would need minimal adjustments.
Impact:
Hard to say. It may be sufficient to just add another notation for binary integer literals per #19308. Or we could do this and lay the issue to rest for good.

In Go, I have never wanted to write an integer literal with radix other than 2, 8, 10, or 16. I have also never read code that would have benefited from these. Therefore, the benefit seems extremely low.
The fact that the existing hexadecimal syntax doesn't fit directly into the proposed syntax but requires a special case of 0 ≡ 16 significantly detracts from the appeal.

I like the idea of removing the leading-zero octal notation.
That's a source of annoying errors, and simplifies explaining the language for new users ("don't do this, you'll be surprised" vs not mentioning alternate base notation till it is needed).

@cespare I would formulated your 2nd paragraph slightly differently:
The fact that the existing hexadecimal syntax neatly fits directly into the proposed syntax significantly adds to the appeal.
:-)

While I see the appeal of having a consistent syntax, I fear this would become a very obscure feature. I never felt then need for anything else but binary, octal, decimal and hexadecimal integer constants.  Binary integer literals are useful in many cases involving bit twiddling, octal is useful for file permissions,  hexadecimal is useful for compact notation of bytes. But trinary or twentyone-ary, seems to be useful for obfuscation only.
I do like the idea of changing then notation for octals, now it's still the confusing C notation. And I do like the uniform notation you propose. I would just disallow anything else than base 2, 8, 10 and 16 to avoid such obfuscation.
Otherwise, could you please show us a few production open source code bases where the use of such arbitrary radix integer constants would have been beneficial?

I'd be ok with the restriction to 2, 8, 10, and 16, but why?

Because that's 32 = 36-4 fewer bases you need to understand when reading code.
23xag56m?  It gets very confusing very quickly. I think I'd rather see ((((10*23+16)*23 + 5)*23 + 6)*23 + 22 or something (an exponent operator would help here).
Hexidecimal is certainly useful.  Binary and octal seem marginally useful.  Other bases just don't seem useful at all.  Certainly their value isn't worth burdening the reader with them.

I am interested in smalltalk you mentioned. Could you point out any open
source smalltalk project that uses arbitrary bases to good effect? My
feeling is that the feature will be rarely used and more of a source of
frustration due to typos as you mentioned.
Op do 18 okt. 2018 22:35 schreef Robert Griesemer<EMAIL_ADDRESS>
:

I'd be ok with the restriction to 2, 8, 10, and 16, but why? It would make
things (a tiny bit) more complicated; the only reason I'd see is that it
might perhaps eliminate errors (somebody might write 9x066 rather than
8x066 for a file permission).
I agree that most programmers may not care much about the flexibility
here, they'll be just fine that they can write down numbers in all the
commonly used radixes (2, 8, 10, 16) w/o extra cost (one extra char for
octal) and use a single, uniform notation.
Personally, I think that not having arbitrary radix notation is what
prevents us from thinking it might be useful. Now usefulness alone is not a
criteria for adding something to the language, but it this case it would
address the desire for a binary notation and simplify what we already
have, and remove restrictions. Seems like a win-win to me. Keep in mind
that there's really strong support for adding binary integer literals, so
no matter what, we'd have to make changes in all the same places. The
difference is just whether we add one more special case, or whether we
simplify all the code in favor for a uniform notation.
Finally, there's also the educational aspect of Go: Having a simple,
uniform mechanism here rather than an agglomeration of historical notations
seems like a nice cleanup.
Btw., Smalltalk supports arbitrary radix notation, too, using the same
syntax but with an 'r' instead of an 'x'. Using the 'x' permits the most
common other base notation fit neatly into the system.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/28256#issuecomment-431149976, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEWeZnI7__f-aPsJ80oMkgO3dGTQUOTks5umOYtgaJpZM4XlECl
.

I'd be ok with the restriction to 2, 8, 10, and 16, but why?

I don't think we should use this proposed syntax with such a restriction. I think that, if anything, we should just add the 0b syntax for binary literals and be done with it (then Go will have all of base 2, 8, 10, and 16 literals).

a single, uniform notation

I don't agree that this proposal is uniform; it introduces more ways of writing the same integer literals:

As you mention in your proposal, the existing octal syntax doesn't match, so there will be two different ways of writing octal integers unless we take the further, backward-incompatible step of removing the current octal syntax.
The current way of writing hex integers doesn't exactly fit into the scheme, so the proposal includes a special case for 0 to have the same meaning as 16. There will forever be two ways of writing hex integers: 0x2a and 16x2a.

@beoran I don't know of a Smalltalk playground offhand (which doesn't require installation), but there of course Squeak (https://en.wikipedia.org/wiki/Squeak). For documentation see the famous "Blue Book", http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf, literals with radixes are described on page 19. And the examples there are limited to radix 8 and 16.
Again, I have no strong feelings regarding restricting a radix to 2, 8, 10, 16, but I also don't think it matters much - people won't use crazy radixes for no good reason. (I suspect it's the small radixes that are interesting. For instance, I can see how I'd use a small-n (3, 5, etc.) radix to encode multiple values of n states in a single int, e.g. for some state on a game board.)
In summary, it really doesn't matter all that much; what people seem to want is binary integer literals, and there's a specific proposal for that. It happens to do what all other languages do (which is good) but it also happens to introduce yet another notation. I've submitted this proposal because I think it's a viable alternative. Especially if we're considering removing/improving the octal notation (which would be a Go 2 item) we'd have to have some replacement. This proposal would resolve all those issues in one fell swoop. Personally, I think this is a more elegant approach for the whole problem of different radix integers, but I'm biased, of course.
I think the decisions that need to be made are:

Do we want a binary integer literal notation? If no, both proposals are moot.
If we have a yes for 1): Do we want to just add the 0b... notation, or alternatively do this proposal (with restrictions to 2, 8, 10, 16; or even just 2, 8, 16).

I think the decision for 2) should take into account:

Do we want to do anything about octals? If no, both proposals are roughly equivalent. If yes, I believe this proposal is stronger as it will address octals uniformly.

For instance, I can see how I'd use a small-n (3, 5, etc.) radix to encode multiple values of n states in a single int, e.g. for some state on a game board.)

There is also the suggestion to support intN for all N from @jimmyfrasche:

another way to handle this would be to create a new class of paramaterized integer types. This is bad syntax, but, for discussion, let's say it's I%N where I is in an integer type and N is an integer constant. All arithmetic with a value of this type is implicitly mod N.

And several real world uses immediately occurred to me:

When working on a RISC-V port, I wanted a uint12 type, since my instruction encoding components are 12 bits; that could have been uint % (1<<12). Lots of bit-manipulation, particularly protocols, could benefit from this.

I can see game states similarly benefitting from intN.
In contrast, I can't think of any real world use cases for arbitrary radix constants. Just another data point.

To answer your questions, I think, 1. yes we need binary constants because they are useful for bit masks and other bit twiddling. And 3. Dropping C style octals and replacing them is a good idea, because C style octals are a source of beginner bugs. Though I would probably go for 0o765 notation, although seeing the Smalltalk precedent 08x765 would also be ok.
As for 2. Actually I don't care too much either way about the notation, as long as we limit it to bases 2, 8, 16 and maybe 10.

The choice of x is poor because it reads as multiply in 4x23 and I have to correct that, interrupting flow. We've trained ourselves to know 0x is hex, partially by knowing multiplying by zero is pointless. Using x feels like a wheeze just to remove 0x as one of the special cases. gri points out Smalltalk uses r; Ada uses #, as in radix#digits#, but it seems a shame to waste that unused character for this.
The referenced issue calling for binary literals has quite a lot of voices saying they're not needed. I won't paste in arguments from there to here, but it's not clear to me that the case for needing them has been made.
More literal bases is a step towards Perl's There's more than one way to do it and away from Go's gofmt. It widens an argument over how some literals should be written and we'll see calls for gofmt, vet, and lint to stand in judgement. Some programmers have never mastered hex, see that other issue, and will want 2x11111111110 because 0xffe is unreadable.
Yes, that was a deliberate mistake to show few readers will want to count a run of the same digit so then there will be calls for underscores, a la Ada, as separators, with arguments over where to separate. It doesn't matter those programmers won't be coding on your project; you and I will still have to read their project.
It's a shame octal nabbed 0755 instead of 0o755, no capital O allowed, but other than that things seem fine as they are. And deprecation of 0755 for a new octal format can be done, as gri outlined, without adding base 2 or base 2-36.

Some programmers have never mastered hex, see that other issue, and will want 2x11111111110 because 0xffe is unreadable.

It's hard to believe there are programmers that can mentally reason about 64 digit binary literals but not hex. The digits are not zero padded so to even determine what bit is set, you need to determine the number of digits in the number. Easy with base16, but are there really any examples of binary integer literals serving a useful purpose other that tables of constants rendered by a monospaced font that are rigorously whitespace alligned or zero padded? The gofmt is not going to move these numbers to the right either. Small values will be difficult to see clearly. I suppose that could  solved by using 2b01 and 2b10 though.

To make binary literals more readable some languages also allow the use of separators. For example, in C# you can write something like this
0b0010_0110_0000_0011
In fact, C# allows underscore to be used in any numeric literal, not only in binary ones.

Sorry, I didn't mean to drag this back to a rerun of #19308, but to point out that widening the choice of ways to do something, write 0xffe, ripples out into formatting and tools.
What demand there is for base 2-36 could be lessened by two things touched on in earlier comments. Keith gave an example for it being easier to read the manual multiplication and addition for a base 23 number. Syntax for array multiplication, AKA Hadamard product, perhaps introduced for vector instructions, would give an alternative. As he said, an exponent operator would help.
base23 = [6436343, 279841, 12167, 529, 23]
ag56m = base23 * [10, 16, 5, 6, 22]

That would also allow for mixed-radix numbers; units of time being a common example.
Josh referred to intN for all N, e.g. int12. That might be too general, and uintN for 1 ≤ N ≤ 32 good enough for most cases. Verilog has something similar and combined with a bit-catenate operator allows x<<18 | y<<5 | z to be x :: y :: z, with :: picked at random. This removes the overlap error where x should have been shifted by 19 to avoid y, and means typed constants with many bits overlaying fields of varying widths can be written more easily as their parts: uint3(2) :: uint13(0x1f0a) :: uint5(0x0f). This is handy when the fields don't fall on nibble boundaries; compare 0xbe14f.
I'm not strongly arguing for either of these, just pointing out that if there is any movement towards them then they overlap with the need for a base 2-36 notation.

In fact, C# allows underscore to be used in any numeric literal, not only in binary ones.

Also Perl.
$ perl -E 'say 123_456_789;'
123456789

In fact, C# allows underscore to be used in any numeric literal, not only in binary ones.

Also Perl.
$ perl -E 'say 123_456_789;'
123456789

Also python.
>>>print(123_456_789)
123456789

Java,
jshell> System.out.println(123_456_789)
123456789

I expect there's quite a few languages that permit underscore in some numeric literals. Ada was just the first I encountered. Like ditching 0751 as the octal syntax, these underscores would seem to be orthogonal to whether base 2-36 is required. They can be an aid to readability on long literals, but also allow more formatting choice by the author, and disagreement with everyone else. (Perl accepts 3._1__4_ for 3.14, though warns if warnings are explicitly requested.)
It's tempting to dictate the allowable formats, e.g. integers must either no underscores, or they must be every three digits from the right: 2_718_281. Hex could be split on nibble boundaries, etc. But that rules out splitting based on the field boundaries underlying the literal, e.g. a 12-bit nibble-aligned field.

Although I'd normally welcome improvements to the numeric aspects of the language, I'm finding it very hard to get enthused about this proposal.
The demand just doesn't seem to be there for bases other than 2, 8, 10 and 16 and, even it was, I don't think the change could be made in isolation.
People would then be asking for a simple way to print these numbers out. Currently the formatted print functions in the standard library support only the standard bases with their %b, %o, %d and %x verbs so new verbs would need to be added to print out values for arbitrary bases. In other words what are already very complicated functions would become even more so.
Nor do I like the proposed syntax. The use of the letter 'x' as a divider seems inappropriate as the other radixes have nothing to do with hex and for the highest radixes it's even a digit itself. I also dislike the discontinuity for hex itself when 16 suddenly becomes 0.
It's worth remembering that we already have support for radixes from 2 to 36 in the strconv package with the FormatInt and ParseInt functions. Although string based and hence relatively inefficient, I'd have thought this should be enough for anyone who wants to play around with different radixes for educational purposes.
Although on balance I'd support it, I'm not even sure that adding binary literals (with a 0b prefix) is such a great idea unless a digit separator (such as _)  is introduced at the same time. The reality it that once you get past one or two bytes, binary literals become unreadable.
As for octal, if one surveys the current state of C family languages, the traditional ones (C, C++, Java) all use the leading zero notation and the newer ones (Swift, Rust) use an 0o prefix.
It seems to me that compatibility with the former is much more important for Go and that the leading zero notation should therefore be retained. As no one appears to be seriously complaining about this, it's just not worth the hassle of changing it.
Having said that, if binary literals are introduced, then for the sake of consistency I wouldn't necessarily be against adding an alternative 0o prefix for octal with people being advised to prefer that unless they were using cgo.

I don't think Go needs compatibility with any language, especially C/C++. Go is already quite different from C family of languages that there's no point in clinging to them. If we're going to look elsewhere we should really look at what modern languages are doing, not the ancient ones that riddled with questionable design decisions and years of backwards compatibility. If we were to add 0b prefix it would be really preferable to also change 0 to 0o just for the sake of consistency. gofixing it would be really easy.

I'm not denying that the leading zero syntax for octal was a questionable design decision for C in the first place. It's more a question of what people expect and anyone coming to Go from the traditional languages is going to expect it to deal with octal literals in the same way.
Also it's not just a matter of go fix changing 0 to 0o. You'd also need to change the language to prevent non-zero integer literals from beginning with 0 at all, otherwise the change could potentially be very confusing.

Given the feedback so far, I am going to narrow the proposal as follows:

We change integer literals to

int_lit = decimal_digit { decimal_digit } [ ( "x" | "X" ) radix_digit { radix_digit } ] .

but only permit 0, 2, and 8 as radix prefix; i.e., integers literals are either decimal, hexadecimal (0x) binary (2x), or octal (8x), and the radix_digit must be within the range 0...radix. (If we wanted to add radix 10 and 16 for regularity, that would be fine, too.)

We disallow octal integer literals in the current form (that is, we disallow non-zero integer literals starting with 0) but have gofmt accept them and automatically rewrite them into the 8x form. For instance, an octal 0677 might be rewritten to 8x677 (or perhaps 8x0677).

This fixes potential confusion with octals, and the stream-lined notation can be extended trivially (and in the obvious manner) should there ever be a need for another radix.
The analogous alternative to this reduced proposal would be #19308 (binary integer literals) modified/extended such that we remove octals in the current form and add the "0o" prefix for octals instead. This alternative would be less regular in notation and extending it would require inventing a new prefix, but otherwise would be about the same.
Independently of this, one might consider #28493 for improving readability of long literals.

I'm still not keen on the 2x and 8x prefixes and would much prefer your alternative notation of 0b and (if we must change octal) 0o.
That would be consistent with the verbs in the formatted print statements and also with what Swift and Rust do.
If we are to have binary literals then, in the interests of readability, I think #28493 is a necessity and it would also help with other long numbers.

Hi @griesemer, I realise from your opening Discussion that reusing the x is to lessen the change, but 8x32 just looks wrong because the x unconsciously reads as times. If hex's syntax had been 0h instead of 0x then I guess the proposal would be 8h32. That reads no better and it's because x and h are both mnemonic for hex and trying to contort them to another purpose goes against that long-learned language-agnostic connection.
0b and 0o have fans because they continue this mnemonic use of the letter. If you want a syntax open to future radixes then adopting a new letter avoids thwarting what's already learnt, e.g. r for radix in 8r32. Rewriting octal is already being considered, partially to avoid the beginner error of leading zeroes on base10. If that just leaves 0x as an oddity, given a new 0r syntax, then, 16r0fc0 is at least consistent, but it's noisy compared to the leaner 0x0fc0 that we all love, and parse without thinking. :-)

That's a good point about x reading like a multiplication symbol.
I find it difficult to imagine any base outside 2, 8, 10 or 16 becoming popular in the future but, if one did, then other languages would also be under pressure to support it. Perhaps a consensus might then emerge on the best notation to use which Go could follow rather than coming up with its own.

Bases other than 2, 8, 10, and 16 are extensively used for example in the handling of Bitcoin, Ethereum, and IPFS  (all of which have existing implementations in Go).   Whilst it's true that all these projects exist and thrive without having base 32 and base 58 literals available, there is no good reason why programmers who frequently use that base should make their code less readable or less expressive.
I think Robert's proposal is perfect, he doesn't seem to have overlooked anything.
If I were forced to complain about anything, that would be that I'd like to see this feature support up to base 58 for reasons stated above, but I reckon that may be a little too much to ask, because there are various different base encodings for bases above 36.  (for example, the alphabet for Bitcoin's base 58 encoding is crafted to remove ambiguity in numbers as read by humans, that's the reason there are no Bitcoin base 58 addresses containing the character l  (lowercase L), to avoid confusion with the number 1. So that's the reason that makes me think the base 36 upper bound is good enough, it corrects the glaring omission of base 2, it's a consistent syntax for any integer literal, it promotes readability, and easy learning one single rule for all bases.
It's as perfect as solution as you can get.  Good work, @griesemer.

@htrob ISTM that you're really arguing here for a base32 encoding to be added.
base58 would be out of the question because, unless we distinguish between upper and lower case letters (which wouldn't fit in with hex), we simply don't have enough potential digits and, even if we did, some of them are omitted by base58 as you've pointed out yourself.
With the exception of base32hex, base32 also suffers from having several different alphabets which are not consistent with the original proposal
My view is that it's best to process them as strings or byte slices as we do now.

Or perhaps, for the more exotic bases, better compile-time evaluation of pure functions applied to constants.  E.g.
x := EthB58("WQERDSFDEdjhjjdk11234567")

That by itself wouldn't make the result eligible for use as a constant, however.

@htrob  Well, I detailed my concerns about the original proposal at some length in my first post to this thread. But, as @griesemer has since narrowed it to only allow 0, 2 and 8 as radix prefixes, there's not much point in going over the same ground again.
The question now is whether 2x or 8x should be preferred to the more familiar 0b and 0o which he offered as an alternative. As I don't like the use of x for  various reasons, I'm firmly in the latter camp.

It's always been clear what's your position, and I still honestly believe it's wrong. I already explained exactly why I think it's more practical, readable, and useful to the new Go programmer going forward to accept @griesemer's proposal, which I believe made a far more solid argument than "I don't like".
No amount of "I don't like" is likely to convince me that I shouldn't state what I believe is a better way. It's agree to disagree territory I guess, so... yes, I agree there's no point in going over matters of your personal preference. Cheers.

The status quo in integer literal is IMO more than sufficient wrt what's needed. Even plain decimal only would be perfectly enough, just use a comment.
const LaunchMask =<PHONE_NUMBER>91328 // 1000 0001 0000 0000 0000 0000 0000 0000 0010 0000 0010 0000

But I don't want to see such monstrosities, as the comment is, in source code. As a comment it's just fine.

At least with binary literals you can write tests.

Tests can be written without them as well.
func TestFoo(t *testing.T) {
        n, err := strconv,ParseUint(strings.Replace("1000 0001 0000 0000 0000 0000 0000 0000 0010 0000 0010 0000", " ", "", -1), 2, 64)
        if err != nil {
                t.Fatal(err)
        }

        if g, e := n,<PHONE_NUMBER>91328; g != e {
                t.Fatal(g, e)
        }
}

Also, I have yet to see a test that tests for the equality of a constant against a literal value. I think vet would not be happy about that.
Can we estimate the share of programs that would ever use, per this proposal, something like an int literal 2x100000010000000000000000000000000010000000100000?
My guess is it might be well less than a promile and that's another reason why I'm not in favor of the proposal.

@cznic I fail to see the relevance of this test to my argument. My point is, your comment might be wrong. People will see it, rely on it and report bugs or simply waste time until discovering that the comment was wrong and they need to manually check the bits in the calculator. One can argue that no comment at all would be better.
I'm not talking about testing the exact value of a constant. Its value could mean some feature flags that you could pass to your function during tests. Very common for libraries to have constants with default flags set. With wrong comment tests would be green. With an error in a binary literal tests could immediately catch it.

Can we estimate the share of programs that would ever use, per this proposal, something like an int literal

Binary literals are useful even for much smaller literals. Share of programs would be meaningless as it very much depends on the nature of a program. Binary network protocols, stuff that deals with hardware, emulators - they all could benefit from this proposal. But if we take some REST API service - it doesn't need binary or even hex literals.

Binary literals are useful even for much smaller literals.

But those are IMO way better readable when written in hex.

I am going to retract and close this proposal. With the reduction to 3 radixes at best (0x, 2x, 8x), it doesn't really bring enough "bang for the buck"; especially so if we keep the existing octal notation. Thanks to the initial supporters, but there doesn't seem to be enough community support for this idea at this stage of Go. If we are going to introduce binary integer literals, we should follow established practice in other languages and go with proposal #19308. If we want to introduce another octal notation, we may want to go with the 0o prefix (another more established convention).
Closing.

After seeing what a bike shed this became, I think closing this is the best
idea. Thanks for your continued efforts.
Op wo 7 nov. 2018 22:57 schreef Robert Griesemer<EMAIL_ADDRESS>
Closed #28256 https://github.com/golang/go/issues/28256.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/28256#event-1952841191, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAEWeXoYwNeXvQqJvo5GYH56rAdCg7XWks5us1dHgaJpZM4XlECl
.

Will #19308 be re-opened? Not much more to say, but it seems odd to request feedback in a blog post and then link to a locked issue.

we may want to go with the 0o prefix

That may be more clear than present. It would also be a simple feature to sort out breaking language changes:

introduce the new syntax in 1.13
eventually remove the existing, slightly more confusing, syntax -- at least for new code

I unlocked #19308.


Enable certificate automation

Set useCertificateAutomation: true for all external domains in radixconfig.yaml.
How to can be found here: https://www.radix.equinor.com/guides/external-alias/#configure-certificate-automation-service

Certificate automation has been enabled for the following environments ✅


Python data processing engineer (RE2) @BSC

More information about the position can be found here.

About BSC
The Barcelona Supercomputing Center - Centro Nacional de Supercomputación (BSC-CNS) is the leading supercomputing center in Spain. It houses MareNostrum, one of the most powerful supercomputers in Europe, was a founding and hosting member of the former European HPC infrastructure PRACE (Partnership for Advanced Computing in Europe), and is now hosting entity for EuroHPC JU, the Joint Undertaking that leads large-scale investments and HPC provision in Europe. The mission of BSC is to research, develop and manage information technologies in order to facilitate scientific progress. BSC combines HPC service provision and R&D into both computer and computational science (life, earth and engineering sciences) under one roof, and currently has over 800 staff from 55 countries.
Look at the BSC experience:

BSC-CNS YouTube Channel
Let's stay connected with BSC Folks!

We are particularly interested for this role in the strengths and lived experiences of women and underrepresented groups to help us avoid perpetuating biases and oversights in science and IT research.
Context And Mission
The Earth Science department at the Barcelona Supercomputing Center searches for a data engineer to work on data standardisation for Earth Sciences. The work includes two separate parts of the data standardisation.
The first part consists of the lead of the work package 2 of the European project Climateurope2 (https://climateurope2.eu/). This project aims at supporting and standardising climate services in Europe and beyond, and the work of this work package is to identify existing standards and potential gaps to describe (meta)data , identify best practices and user requirements in provenance and lineage information and ways to present them as well as defining and enhancing verification and certification methods that are required to provide quality assurance and FAIRness of data, processes and products.
The second part of the work is more oriented to code development and optimization in python using data standardisation tools of the climate community to convert data to netCDF following the CMOR conventions. Such developments are required to improve the department tools and for tasks in ongoing European projects due to the increase of resolution of the climate models. It includes optimization on High Performance Computers, deployment and including of new features in existing tools.
The successful candidate will work in the Data and Diagnostics Team, from the Computational Earth Sciences Group in very close collaboration with the Earth System Services and Climate Variability and Change groups’ scientists.
Key Duties
Co-lead the meetings and work of ClimatEurope2’s work package 2
Improve the computational performance of the CMORization packages of the department
Contribute to the maintenance and development of new features of CMOR tools
Requirements
Education

Having a Bachelor in Computer Science, Engineering, Physics or related discipline.
Essential Knowledge and Professional Experience
Good development skills in Python
Knowledge of Earth Sciences formats and standards (CMOR, netcdf, CF…)
Experience with UNIX/LINUX environments, scripting languages (bash, …) and version control systems (git, or svn) will be valued
Experience in Earth Sciences tools and libraries (CDO, NCO, xarray,…) and managing large volumes of data will be appreciated
Keen to learn on how to develop scientific applications on parallel computers

Competences

Capacity to interact and build strong relations with both climate and computer scientists
Excellent written and verbal communication skills
Ability to take initiatives, prioritize the tasks and work under set deadlines
Ability to work both independently and within a team
Ability to learn and adapt to multiple programming languages easily
Fluency in English, both speaking and writing

Conditions

The position will be located at BSC within the Earth Sciences Department
We offer a full-time contract (37.5h/week), a good working environment, a highly stimulating environment with state-of-the-art infrastructure, flexible working hours, extensive training plan, restaurant tickets, private health insurance, support to the relocation procedures
Duration: Open-ended contract due to technical and scientific activities linked to the project and budget duration
Holidays: 23 paid vacation days plus 24th and 31st of December per our collective agreement
Salary: we offer a competitive salary commensurate with the qualifications and experience of the candidate and according to the cost of living in Barcelona
Starting date: asap

Applications procedure and process
All applications must be made through BSC website and contain:

A full CV in English including contact details
A Cover Letter with a statement of interest in English, including two contacts for further references - Applications without this document will not be considered

Have been invited for an interview. Thanks, God 🙏🏾

Thank you, Jesus Christ. This has been successfully completed.


Document Array#shift?

Welcome back @porras :+1:

I don't think the build failure is related to the change...


Added Code Review to Contributing.md

Fixes #79
Checklist

[x] I have made a material change to the repo (functionality, testing, spelling, grammar)
[x] I have read the [Contribution Guide] and my PR follows them.
[x] I updated my branch with the master branch.
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation about the functionality in the appropriate .md file
[x] I have added in line documentation to the code I modified

Short description of what this PR does:

Added Code Review to Contributing.md

If you have questions, please send an email to Sendgrid, or file a Github Issue in this repository.

Closing all open issues and PRs. This repo is no longer maintained. Please use https://github.com/sendgrid/sendgrid-nodejs/tree/master/packages/client instead.


[IMPROVEMENT] Remove isCLIAPIVersionOne related codes

Is your improvement request related to a feature? Please describe (👍 if you like this request)
Many codes (isCLIAPIVersionOne) in longhorn-manager are handling incompatible instances. The ticket aims to see if the codes can be removed and simplify the codes.
Describe the solution you'd like

Describe alternatives you've considered

Additional context

Verified pass on longhorn v1.8.0-dev-20241006 (https://github.com/longhorn/longhorn-manager/commit/f3d710b4cfd4b3c4278eb0a78d8b52043f6a57d0)
Did not observe outstanding issue related to longhorn-manager in master pipeline after the change

longhorn-tests-sles-amd64 build 1072 - 1 failure
longhorn-upgrade-tests-sles-amd64 build 927 - 2 failures


bwd optimizing based on profiling

Updated ck backend.
Enabled qloop light version.
Optimizing bwd based on profiling.
Kloop is removed.
Tests have been done based on mosaicML problem sizes.
Perf of fwd with dropout can improve up to 32%.
Perf of bwd can improve up to 54%.

The tolerance error of dropout fraction has been temporarily set to 2%.


chore(ci): Remove pass-checks workaround due to merge queue disabling

Remove the passchecks workflows that were required for merge queues since we are disabling merge queues.
See relevant discussion on Slack:
https://firezonehq.slack.com/archives/C04HRQTFY0Z/p1696090214535859

Hmm, actually I'm not sure we want to remove this. I don't think GH will enforce required status checks otherwise.


ypspur_ros: 0.3.6-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository ypspur_ros to 0.3.6-1:

upstream repository: https://github.com/openspur/ypspur_ros.git
release repository: https://github.com/openspur/ypspur_ros-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: 0.3.5-1

ypspur_ros
* Avoid publishing joint messages with duplicate stamps (#115 <https://github.com/openspur/ypspur_ros/issues/115>)
* Update assets to v0.6.2 (#114 <https://github.com/openspur/ypspur_ros/issues/114>)
* Update assets to v0.6.1 (#113 <https://github.com/openspur/ypspur_ros/issues/113>)
* Update assets to v0.6.0 (#112 <https://github.com/openspur/ypspur_ros/issues/112>)
* Update assets to v0.5.2 (#111 <https://github.com/openspur/ypspur_ros/issues/111>)
* Update assets to v0.5.1 (#110 <https://github.com/openspur/ypspur_ros/issues/110>)
* Update assets to v0.5.0 (#109 <https://github.com/openspur/ypspur_ros/issues/109>)
* Update assets to v0.4.2 (#108 <https://github.com/openspur/ypspur_ros/issues/108>)
* Update assets to v0.4.1 (#107 <https://github.com/openspur/ypspur_ros/issues/107>)
* Update assets to v0.4.0 (#106 <https://github.com/openspur/ypspur_ros/issues/106>)
* Update assets to v0.3.4 (#102 <https://github.com/openspur/ypspur_ros/issues/102>)
* Update assets to v0.3.3 (#101 <https://github.com/openspur/ypspur_ros/issues/101>)
* Update assets to v0.3.2 (#100 <https://github.com/openspur/ypspur_ros/issues/100>)
* Contributors: Atsushi Watanabe, Mark Hedley Jones

Holding for Noetic sync


Fixing screen orientation issue for different devices

The navbar may need some responsiveness fixations. Please let me do this task!

@DuckStruggles Another contributor is already working on making the navbar responsive. Please work on any other issues.


Put settings to database

We need to store settings in database because all settings that are present in karaf assembly get overwritten during SS update. Also we need to prune unnecessary settings such as *Enabled ones and review the rest of the settings. Storing settings in db also will remove problems withsychronization between db settings and file settings.

Removed ,security settings from properties file. Added new DAO managers and Entity classes to system-manager module. Moved part of the configs into Database.


build and report correct target os/arch

This patch updates the initLogger() and PrintVersion() functions to use the correct flags for reporting a build's target os, arch, and go version at runtime from the compiled binary.
Signed-off-by: James Ranson<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

17 of 17 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 94.372%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
16031

Relevant Lines:
16987

💛  - Coveralls

this finishes out #606


Proxy is bad problem

Can you please tell me the syntax of the proxy

Also need this. thanks

where will you recommend i buy proxies from?


Allow for more, smaller buck mounts and trays

Referencing my line of thought on Twitter:

First idea: Half-sized lower bay trays, to allow mounting up to four, smaller trays.

You could still simply use two large trays and keep the extra room.
This only requires adding 2 or 4 screw hole pillars that are otherwise unused.

Tested both sizes of new template.
Mount generator template implemented
Old bay trays are updated as needed


Support for tf df trees #181

@parrt it contains the visualisations for Random Forest algo. The tensorflow DF contains more algorithms for decision forests and we can add them also in the future.
close #181

hooray!!!  The tfdf prefix looks very much like the common term tfidf... Perhaps we change that to simply prefix of tf everywhere?

There are a couple of changes such as in interpretation.py that might affect other targets. Have you run through and checked the other kinds of trees and run tests?

There are a couple of changes such as in interpretation.py that might affect other targets. Have you run through and checked the other kinds of trees and run tests?

yes, I spent some time for these changes and ran/tested all of them :)

hooray!!! The tfdf prefix looks very much like the common term tfidf... Perhaps we change that to simply prefix of tf everywhere?

agree, I will rename them soon.

Thanks, @tlapusan !


Make default distribution logic divide work evenly.

Also fix a bug in tile size adjustment, which reduce the number of workgroups in cases where we are dividing the work too much. The numWorkgroupsPerDim[index] was not updated after adjusting it to a new tile size.

The regressions and improvements are noise. Good to have dispatch size improvements!

For future reference, Diego and I had an offline discussion. It's ok if there is a bit of load imbalance. We just have to make sure that the gap between the first N-1 and the last one is not huge. I added hints to make distribution tile sizes be multiple of the vector length. It makes sure that we are not penalizing all the threads.

@dcaballe I think this is the root cause that regresses some benchmarks. We can't simply revert it because one of landed commit depends on it. I will prepare a PR that reverts it properly later today.

I checked that the regression only happens on MobileBert_int8 case, and filed an issue. I think we should fix that after we have better int8 codegen. The configuration was tuned by me and it just unrolls a lot. We don't get a chance to fix it. I'd defer the multi-threading issue after fixing codegen. Otherwise, we will sit in the sub-optimal configurations for a long time. And it will be much harder to contribute.


Update galley, weft and path-mapped-storage version

I'll merge this as it's just a version update for new release.


Build merge-to-main-cart on avocano-cart: FAILURE

Cloud Build encountered an error:

Project: avocano-cart
Trigger: merge-to-main-cart
Commit: 3232129 on branch main

View Logs
I'm an automation.  Googlers: go/avocano-admin-notifiers

another timeout


Problems with stereo playback at specific speeds

There appear to be issues with playing back stereo files at specific rates - I've tested 2.5x and 2.25x, but suspect it can be generalised to rates of the form N+1/(2^m) (N and m are integers).
There may be more than one issue here. I'm highly suspicious of, for example, ResamplingReader.h:359
_interpolationPoints[channel][3].y = getSourceBufferValue(_bufferPosition1-(i*_numChannels)+1+channel);
which looks suspiciously as if it's going to read data from the wrong channel - I did a quick fix of
_interpolationPoints[channel][3].y = getSourceBufferValue(_bufferPosition1-(i*_numChannels)+_numChannels+channel);
and the output was better, but not entirely fixed.
I think the main issue could be due to differences shuffling the interpolation values around - I've added a few lines to fill in the x member with the buffer position used to generate the y value, and got some weird results where values looked to be older than expected (I'd expect, for a stereo file, to get x values of X, X-2, X-4 and X-6 - but I don't).
Having said all that, I don't fully understand the code and there's a lot of repeats of "shuffle up the interpolation points and refill" with subtle differences, so I'd rather you have a look and do the thing properly, if possible! If I do it, I'm liable to leave a few cases untouched, or even more broken than before...

I'll have a quick look if I can find some time. yes sorry the interpolation code is horrific, I've been wanting to sort it out for a while, theres a few things wrong... the earlier versions of this library had a better approach for interpolation, there was an array containing the last 4 samples (per channel) which were sampled on a whole number...

Hmmm ... I thought that was pretty much the current approach?! It just seems that the "last 4" are not managing to be the actual last 4, but have gaps in. Something to do with how you do the calculations with _remainder and _playbackRate, I think, and turn it into an array-filling loop.
On the value getting, I did a fix putting in a protected function

int16_t _getSourceBufferValue(int bufpos, int sampleOffset, int channel)    {        return getSourceBufferValue(bufpos + sampleOffset*_numChannels + channel);    }

and then using that everywhere getSourceBufferValue() was previously used. Should be OK, I think C++ inlines it.

By the way, thanks for (possibly!) taking time to have a look - much appreciated.
And I forgot to say, the overflow protection code in fastinterpolate() needs to be enabled - I got some overflows with a 100% amplitude 330Hz sine wave played back at ... 2.5x. That does seem to be a problem value!

https://github.com/newdigate/teensy-variable-playback/tree/fix/rate_two_and_a_half
does that fix the issue?

Nope, don't think so. Caveat, I haven't checked out the repo, just made what I believe is the equivalent change by editing line 358 to if (false && !_useDualPlaybackHead) {
We now have some gaps in the samples, and some duplicated!

The negative x values are to show the associated y values are from result, not the indexed call to getSourceBufferValue() that should be disabled. Hence they're <minus><the sample number in the file>, left channel sample numbers being even and right channel being odd. I was getting things like -23, -25, -27, -33 before - it looked as if the for-loop is executing only once, and grabbing the last sample, rather than N times.
Also, I put numberOfSamplesToUpdate in as a class member so it would print, and it only ever comes out as 2; I would expect alternating 2 and 3, if the playback rate is 2.5x.

Ah! yes its all coming back now... For interpolation, I used to store the X and Y values of the previous 4 samples, then I changed it to just the Y values... and the X values were hardcoded to 0,1,2,3. I think this issue was introduced then. Give me some time, I'll fix it.
Thank you very much for your help and time!

No worries, always a pleasure to help make something good even better! And thank you for giving of your valuable bandwidth....

Better, in some small way, but still not right, I'm afraid.
Lines like _interpolationPoints[channel][3].y = getSourceBufferValue(_bufferPosition1+(i*_numChannels)-1+channel); are still in there, and wrong - the -1 switches to the other channel in a stereo file! Try something like
_interpolationPoints[channel][3].y = getSourceBufferValue(_bufferPosition1+((i-1)*_numChannels)+channel);
A good test case for this is a stereo file with radically different audio in the two channels - I crafted one with an up-sweep on one, and a reverse of that on the other.
The other issue is this:
for (int i=numberOfSamplesToUpdate; i > 0; i--) {
    _interpolationPoints[channel][0].y = _interpolationPoints[channel][1].y;
    _interpolationPoints[channel][1].y = _interpolationPoints[channel][2].y;
    _interpolationPoints[channel][2].y = _interpolationPoints[channel][3].y;
    _interpolationPoints[channel][3].y = result;
    if (_numInterpolationPoints < 4) _numInterpolationPoints++;
}

This puts in numberOfSamplesToUpdate copies of the same sample, which is clearly incorrect. It also seems to be slightly the wrong sample - I end up with samples N-4, N-3, N, N in the _interpolationPoints[] array when this code fires.
As an experiment I changed if (abs_remainder > 0.0) { to if (true || abs_remainder > 0.0) { and everything works much better!

Hey @h4yn0nnym0u5e. Thanks for the testing/feedback/investigation.
I've had another attempt to improve the interpolation (there is still a tiny error of the first 4 samples will be zero), but I think it works slightly better, now on this branch - If it works for you then I will try to fix the first 4 samples....

Not working for me, still :(
I've been having a go myself, as your changes were helping me understand what is intended (I think...) - you might want to have a crack at this branch.
I think I have interpolation working, and also repeat or pingpong looping with and without cross-fades. I've only tested on-screen using a single file (250ms stereo tone sweep, left rising and right falling), at ±2.5x. I'm hoping to try a wider range of settings tomorrow, using an oscilloscope.
Is it intentional that there seems to be no way to set linear interpolation, just none or quadratic?

I was able to reproduce the issue before, but I'm no longer able to reproduce now, using the fix/interpolation2 branch. The issue with the 2.5 x rate (and 1.5x, etc....) was that when the remainder was 0.0 (i,e. every second sample...), it was assuming there was no jump over a whole number. This is fine when the rate is < 1.0, but when rate = 2.5, it was not detecting the jump and not updating the interpolation buffer. So a better mechanism fixed that issue, storing the last sample index at which the interpolation buffer was updated (per channel).
I tried processing a stereo sweep @ +2.5x with the left channel reversed.... Inspecting the output in audacity looks perfect.

Is it intentional that there seems to be no way to set linear interpolation, just none or quadratic?

I think linear interpolation should be working, I just haven't enabled or tested it for years. It is there for reference and if somebody has a need to reduce the potentially heavy/broken quad interpolation

looking at it..... linear interpolation has the same bug!!! doh! I don't think it'll work well with 1.5, 2.5, 1.25, very well...

ops, sorry correction on line 504 ResamplingReader, should be:
        for(int i=0;i<8;i++) {
            _numInterpolationPoints[i] = 0;
            _lastInterpolationPosition[i] = _header_offset/_numChannels;
        }

it was...
        for(int i=0;i++;i<8)
            _numInterpolationPoints[i] = 0;

....which makes no sense

I have reverted all the changes locally, so I just have fix/interpolation2 branch, re-ran my 2.5 x tests and all seems fine to me... Unfortunately I'm running these tests on x86 cpu, not on a teensy - so the only thing I can say is that the algorithm now works on x86 for 2.5 x playback rate. I thinks its highly unlikely, but it could be a processor architecture issue.
I might move the dual playback head to a different branch because It makes the interpolation code pretty messy...

I've been having another play, and I think my confusion arises from leaving useDualPlaybackHead enabled - this breaks your branch pretty severely, though I know it wasn't on your radar right now.
Observations:

getSourceBufferValue(_bufferPosition1-(i*_numChannels)+1+channel) causes the channels to be swapped - you don't need the +1 as far as I can tell, seems to be in pretty much all the lines where the interpolation buffer is being filled
pingpong loops aren't working
as noted, useDualPlaybackHead isn't working

On my branch I think I got all loop and dual playback working, though I completely re-wrote your crossfade start / stop logic because I simply couldn't fathom it, and it gets really weird if you were doing a crossfade on a pingpong loop, as the bufferPosition indexes are going in the opposite direction during the crossfade. I do need to do more testing, but would welcome any comments you might have.

useDualPlaybackHead
Its a bit of an experimental feature. The concept is easy, but it starts getting a bit tricky when doing the interpolation. Maybe one-day when Im inspired I will reimplement it. For the meantime, its going on a experimental branch.... and I'll remove it from the master.... It should be compatible with all features...

getSourceBufferValue(_bufferPosition1-(i*_numChannels)+1+channel) causes the channels to be swapped - you don't need the +1 as far as I can tell, seems to be in pretty much all the lines where the interpolation buffer is being filled

goitcha. I had noticed the left and right channels were swapped but didnt know why. Thanks.

pingpong loops aren't working

dual playback heads dont need to switch when doing a ping pong, no fade is required when the loop end is hit or the begging is hit, so maybe disable dualplayback head when ping ponging....

I'm finding pingpong not working at all, dual heads or not.
I'm not 100% sure if cross-fading is unnecessary for pingpong: obviously the sample level is the same but the rate of change could reverse rapidly, which may give an audible click similar to a level change. For people tuning their loop points via a front panel control it might be worth leaving in / implementing.
Very weird, I've just noticed my code puts in a glitch, in the left channel only, just after a pingpong reverse! (Without crossfade; with, it either doesn't happen or the crossfade has masked it). Most odd, have to fix that.

Found the glitch - you've got it too... In ResamplingReader.h, line 173, we have
if (readNextValue(index[channel], channel)) {
If the read fails (because the loop is ended), then the else clause is actioned to sort out the buffer position, but the readNextValue() isn't re-tried, and execution proceeds with the other channel (which succeeds because the buffer position is now OK). This means a stale sample is left at the end of the Channel 0 values for this update(), downstream of where the issue really occurred.

ah! makes sense now. well spotted. thank you Johnathan!


Help on running echo client examples

echo_client does not work
./echo_client -H www.example.com -s <IP_ADDRESS>:12345
03:37:01.702 [NOTICE] Connection closed

error info
# ./echo_client -H www.example.com -s <IP_ADDRESS>:12345 -L debug
03:35:30.800 [DEBUG] tokgen: TOKGEN2 does not exist: generate
03:35:30.800 [INFO] tokgen: inserted TOKGEN2 of size 110
03:35:30.800 [DEBUG] tokgen: initialized
03:35:30.800 [INFO] engine: instantiated engine
03:35:30.800 [INFO] socket buffer size: 212992 bytes; max # packets is set to 155
03:35:30.800 [DEBUG] local address: <IP_ADDRESS>:54013
03:35:30.801 [DEBUG] engine: grew heaps to 4 elements
03:35:30.801 [DEBUG] conn: generated and assigned SCID 246BADF1AE6DF544
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] bw-sampler: init
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] bbr: initialized
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] cubic: lsquic_cubic_init(cubic, $conn)
03:35:30.801 [INFO] [QUIC:246BADF1AE6DF544] cubic: initialized
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] adaptive-cc: initialized
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] cfcw: recv_off changed: read_off: 0; recv_off: 15728640
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: created client, DCID: 3EE8D28D7847D649DE85
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: Create new SSL_CTX
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: generated transport parameters buffer of 55 bytes
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: max_idle_timeout: 30000; init_max_data: 15728640; init_max_stream_data_bidi_local: 6291456; init_max_stream_data_bidi_remote: 0; init_max_stream_data_uni: 32768; init_max_streams_bidi: 100; init_max_streams_uni: 100; ack_delay_exponent: 3; max_ack_delay: 25; active_connection_id_limit: 8; timestamps: 2; loss_bits: 1; initial_source_connection_id: 246BADF1AE6DF544
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] di: initialized
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] sfcw: recv_off changed: read_off: 0; recv_off: 16384
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] stream: created crypto stream
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] stream: calling on_new_stream
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] sendctl: send_ctl_can_send: n_out: 0 (unacked_all: 0); cwnd: 46720
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] pacer: lsquic_pacer_can_schedule: 1
03:35:30.801 [DEBUG] engine: incref conn 246BADF1AE6DF544, '' -> 'T'
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: handshake stream created successfully
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: negotiating version FF00001F
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: logging using client SCID
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] event: connection created
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] qlog: [231007458907,"CONNECTIVITY","NEW_CONNECTION","LINE",{"ip_version":"4","srcip":"<IP_ADDRESS>","dstip":"<IP_ADDRESS>","srcport":"54013","dstport":"12345"}]
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] event: version negotiation: proposed version FF00001F
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] qlog: [231007458914,"CONNECTIVITY","VERNEG","LINE",{"proposed_version":"FF00001F"}]
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: record path 0: (<IP_ADDRESS>:54013 - <IP_ADDRESS>:12345)
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: spin bit enabled on path 0
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: record new path ID 0
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: delayed stream creation.  Backlog size: 1
03:35:30.801 [DEBUG] engine: decref conn 246BADF1AE6DF544, 'HT' -> 'H'
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] pacer: lsquic_pacer_can_schedule: 1
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: handshake: error:00000001:invalid library (0):OPENSSL_internal:unknown library
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: handshake failed
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: handshake failed
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: enc level clear after on_write: stop
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: Exit shake_stream
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: sit-0 streams: max count: 0; created streams: 0
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] conn: created 0 delayed streams
03:35:30.801 [DEBUG] engine: incref conn 246BADF1AE6DF544, 'H' -> 'CH'
03:35:30.801 [DEBUG] engine: decref conn 246BADF1AE6DF544, 'CH' -> 'C'
03:35:30.801 [DEBUG] engine: decref conn 246BADF1AE6DF544, 'C' -> ''
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: crypto stream level 0 is closed
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] sfcw: read_off goes from 0 to 0
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] stream: destroyed stream
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544-18446744073709551615] stream: history: [CN320L]
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] pacer: scheduled calls: 0
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] bw-sampler: cleanup
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] bbr: cleanup
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] adaptive-cc: cleanup
03:35:30.801 [NOTICE] [QUIC:246BADF1AE6DF544] sendctl: stats: n_total_sent: 0; n_resent: 0; n_delayed: 0
03:35:30.801 [NOTICE] Connection closed
03:35:30.801 [DEBUG] [QUIC:246BADF1AE6DF544] handshake: iquic_esfi_destroy
03:35:30.801 [NOTICE] [QUIC:246BADF1AE6DF544] conn: # ticks: 1
Floating point exception (core dumped)

echo_server runing
# ./echo_server -c www.example.com,/home/quiche/lsquic/ssl/server.crt,/home/quiche/lsquic/ssl/server.key -L debug
03:34:36.195 [DEBUG] host: <IP_ADDRESS>; port: 12345
03:34:36.195 [DEBUG] tokgen: TOKGEN2 does not exist: generate
03:34:36.195 [INFO] tokgen: inserted TOKGEN2 of size 110
03:34:36.195 [DEBUG] tokgen: initialized
03:34:36.195 [DEBUG] handshake: generated QUIC server context of 38 bytes for version FF00001B
03:34:36.195 [DEBUG] handshake: max_idle_timeout: 30000; init_max_data: 1572864; init_max_stream_data_bidi_local: 0; init_max_stream_data_bidi_remote: 1048576; init_max_stream_data_uni: 12288; init_max_streams_bidi: 100; init_max_streams_uni: 3; active_connection_id_limit: 8; timestamps: 2
03:34:36.195 [DEBUG] handshake: generated QUIC server context of 38 bytes for version FF00001C
03:34:36.195 [DEBUG] handshake: max_idle_timeout: 30000; init_max_data: 1572864; init_max_stream_data_bidi_local: 0; init_max_stream_data_bidi_remote: 1048576; init_max_stream_data_uni: 12288; init_max_streams_bidi: 100; init_max_streams_uni: 3; active_connection_id_limit: 8; timestamps: 2
03:34:36.195 [INFO] prq: initialized queue of size 10000
03:34:36.195 [INFO] purga: create purgatory, min life 30000000 usec
03:34:36.195 [INFO] engine: instantiated engine
03:34:36.196 [INFO] socket buffer size: 212992 bytes; max # packets is set to 155
03:34:36.196 [DEBUG] local address: <IP_ADDRESS>:12345
03:34:36.196 [DEBUG] entering event loop

code  brach

master

system

CentOS Linux release 7.7.1908 (Core)

The test echo example for this branch  (v2.19.4) is running normally.

Thank you for the report -- this will be fixed in the next release.

The error has to do with the ALPN requirements in IETF QUIC, which BoringSSL now enforces.  If you don't care that it's IETF QUIC, you can use gQUIC by adding the version to the client's command line: -o version=Q050.

如果你重写echo_client遇到这个错误，那么加上这个就好了： eapi.ea_alpn = "echo";

https://github.com/dtikhonov/lsquic-tutorial  这里的教程程序也会有这个错误 请加上它 eapi.ea_alpn = "echo";


Fix subtle bug in token context module resolution

I found out that my recent relaxation of DevirtualizationManager
to allow devirtualization across modules within the large version
bubble uncovered a pre-existing bug in token module context
resolution causing about 10% execution failure rate in Pri#1 tests
in release large-bubble mode.
My original implementation (that Michal later expanded to also
cover generated IL thunks) used "pResolvedToken.tokenScope" to
determine the token context. This is however incorrect in the
presence of devirtualization - in such case, JIT only updates
the tokenContext in pResolvedToken to refer to the devirtualized
method, not tokenScope (which continues pointing at the original
method in which we devirtualized a method call). Due to this the
reference module and token value went out of sync, causing a
wrong function to be called.
Thanks
Tomas

Seems like you should instead fix the code in the jit in impDevirtualizeCall where it is creating a resolved token for getCallInfo so it does the right thing...

@AndyAyersMS - Hmm, I've also been thinking about this option; I agree that it would simplify the method context resolution which currently needs to take two different paths for ECMA vs. generated IL. Right now I'm running the complete Pri#1 test file to get a reading on the CQ impact; I'll take a look whether I'm going to be able to figure out how to fix JIT - I stepped through the code in impDevirtualizeCall but I'm admittedly far less familiar with its overall codebase. Any special instructions regarding PR's for JIT changes?

It's this bit of code at the end of the method:
        // For R2R, getCallInfo triggers bookkeeping on the zap
        // side so we need to call it here.
        //
        // First, cons up a suitable resolved token.
        CORINFO_RESOLVED_TOKEN derivedResolvedToken = {};

        derivedResolvedToken.tokenScope   = info.compScopeHnd;
        derivedResolvedToken.tokenContext = *contextHandle;
        derivedResolvedToken.token        = info.compCompHnd->getMethodDefFromMethod(derivedMethod);
        derivedResolvedToken.tokenType    = CORINFO_TOKENKIND_Method;
        derivedResolvedToken.hClass       = derivedClass;
        derivedResolvedToken.hMethod      = derivedMethod;

        // Look up the new call info.
        CORINFO_CALL_INFO derivedCallInfo;
        eeGetCallInfo(&derivedResolvedToken, nullptr, addVerifyFlag(CORINFO_CALLINFO_ALLOWINSTPARAM), &derivedCallInfo);

I was never happy with it and it should be simple to fix. We have the method desc for the method we've devirtualized to, so presumably we can get to the proper scope from there....
Alternatively we can think about some more streamlined mechanism to signal back to the R2R driver about what has happened, we shouldn't really need to go back to tokens.

I think that the only tricky part is that, as of now, tokenScope is the MethodIL in which the call resides. When we devirtualize the call, we have no such MethodIL (because the call to the devirtualized method is not present in any pre-existing MethodIL, we conjured it out of thin air).
We could either provide the MethodIL of the devirtualized method itself - that might be slightly inconsistent with the pre-existing behavior but the token context module resolution would work fine - or generate an IL pseudo-thunk calling the devirtualized method, provide its MethodIL and basically go through Michal's code in both cases. I'll take a look what assumptions Crossgen / CoreCLR runtime have about tokenScope but, frankly speaking, the more I think about it, the more I'm scared about the JIT change.

Hmm, the JIT fix in fact turned out to be trivial but I'm still somewhat confused. How come that for JIT tokenScope is a mere CORINFO_MODULE_HANDLE and in CorInfoImpl we're able to convert it to a MethodIL?

How come that for JIT tokenScope is a mere CORINFO_MODULE_HANDLE and in CorInfoImpl we're able to convert it to a MethodIL?

CORINFO_MODULE_HANDLE is CORINFO_MODULE_STRUCT_* and that's a MethodIL in CPAOT.

Based on PR discussion I have decided to follow Andy's advice and seek JIT-based solution for this issue as it's more systematic and elegant; for this reason I'm abandoning this review.
Thanks
Tomas
P.S. You can find the follow-up reviews here:
https://github.com/dotnet/corert/pull/7755
https://github.com/dotnet/coreclr/pull/26451


bug: Can't open alert with many radio inputs in iOS

Type: bug
Ionic Version: 2.x
Platform: ios 9 webview
Because there is no official number picker in ionic 2, i created my own number picker which is alert with radio inputs, example in ionic lab:
http://oi65.tinypic.com/33ndyzt.jpg
In my galaxy note 5 it's working fine, but in Ionic View - iphone 6 plus, it's not working at all and destroy the page structure(design) for 1-2 sec and back to normal.
Code:
	openAgeSelect(): void {
		this.translateService.get(['intro.steps.age.ageSelectTitle', 'global.alerts.okButton', 'global.alerts.cancelButton']).subscribe((translatedTexts) => {
			let agesInputs = [];
			for(let i = this.appSettings.validations.age.min; i <= this.appSettings.validations.age.max; i++) {
				let inputChecked = false;
				if(this.user.age === i) {
					inputChecked = true;
				}
				agesInputs.push({
					type: 'radio',
					label: i.toString(),
					value: i,
					checked: inputChecked
				});
			}

			let ageSelectAlert = this.alertCtrl.create({
				title: translatedTexts['intro.steps.age.ageSelectTitle'],
				inputs: agesInputs,
				buttons: [
					{
						text: translatedTexts['global.alerts.cancelButton']
					},
					{
						text: translatedTexts['global.alerts.okButton'],
						handler: age => {
							if(age && age >= this.appSettings.validations.age.min && age <= this.appSettings.validations.age.max) {
								this.user.age = age;
								this.goNextSlideWithDelay();
							}
						}
					}
				]
			});
			ageSelectAlert.present();
		});
	}

Hello, thanks for opening an issue with us! Would you be able to post a repo I can use to reproduce this issue? Thanks!

Hello all! As it seems it has been a while since there was any activity on this issue i will be closing it for now. Feel free to comment if you are still running into this issue. Thanks for using Ionic!


Added onDisabledClick prop & now pass event to on{Disabled,}Click

Needed the option to stop the event from bubbling up, so made it such that the event is passed up to the onClick. Also, having a onDisabledClick, means you can feed some info back to the user if they are clicking something when it is disabled.

Thanks for the PR!  I've just merged it and will publish a new version to NPM today.


Create Project Structure with Bootstrap Files

As a Principal Engineer,
I want to create the initial structure of this scraper project, including bootstrap files for the programs we will implement on the client and server sides, so that we can have a solid foundation to build and implement the features required for this project.
Acceptance Criteria:
1. Project Structure

Create a root directory for the project.
Add a folder called client for the front-end development, which will consume the API containing the scraped data. It must be an Angular application.
Add a folder called server for the back-end development, which will be a .NET solution.
Create .gitignore files to avoid syncing junk files from the Angular and .NET projects, as well as IDE and operating system files.

2. .NET Project

Create a classlib project called Lib.Data to store the common models.
Create a classlib project called Lib.Exception to store the common exceptions.
Create a classlib project called Lib.InMemoryDatabase to implement communication with Redis, where we will store sessions.
Create a classlib project called Lib.NoSqlDatabase to implement communication with MongoDB, where we will store scraped data.
Create a classlib project called Lib.SqlDatabase to implement communication with PostgreSQL, where we will store users and other relational data.
Create a classlib project called Lib.Repository to connect all these database libraries and make it simple for the executable .NET projects to consume data.
Create a classlib project called Lib.Security to implement encryption and hashing, mainly used by the authentication system.
Create a webapi project called ScraperApi to implement the endpoints to manage the repositories and consume scraped data.
Create a webapiaot project called AuthServer to implement the endpoints for authentication.
Create a xunit project called AuthServer.Test to implement TDD for the AuthServer.
Create a mvc project called AdminClient to implement a simple server-rendered interface to manage the authentication system.

The commit fulfills the acceptance criteria.


[SPARK-41326] [CONNECT] Fix deduplicate is missing input

What changes were proposed in this pull request?
In the transformation of the Spark Connect plan for Deduplicate, it was missing to copy the input relation into the plan. This caused an exception on the server and failing the query.
This patch fixes that bug.
Why are the changes needed?
Bugfix
Does this PR introduce any user-facing change?
No
How was this patch tested?
UT

Can one of the admins verify this patch?

Merged to master.


SqlServerSecureConnection: Add Parameter RestartService

Pull Request (PR) description
This PR adds a new parameter to SqlServerSecureConnection resource called RestartService. The default value is true because the change requires a restart to take effect. I have added to parameter to allow the restart to be suppressed, as I would like to issue and configure certificates on production servers without restarting them, then manually restart the server later.
Scenario, a SQL Server is already configured with a network certificate which will expire in say 30 days. A new certificate is issued and configured onto the SQL Server without restart. The SQL Server continues to use the old certificate until the service is restarted.  After restart the new certificate is now being used.
This Pull Request (PR) fixes the following issues
Task list

[x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[x] Resource documentation added/updated in README.md.
[x] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[x] Comment-based help added/updated.
[x] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[x] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[x] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #1406 into dev will increase coverage by <1%.
The diff coverage is 100%.

@@          Coverage Diff          @@
##            dev   #1406    +/-   ##
=====================================
+ Coverage    98%     98%   +<1%
=====================================
  Files        37      37
  Lines      5526    5529     +3
=====================================
+ Hits       5420    5423     +3
  Misses      106     106

@Teutenberg I pressed the LGTM button by mistake. 😕 Please resolve/discuss the comments. 🙂

We shouldn't have needed to add the parameter to the calls to Get-TargetResource from the other *-TargetResource functions, but let's fix that later. Looks good to me.


Assets in autocomplete.html example not availabe

Hi,
The assets in the autocomplete.html example file are not available anymore, they throw an 418 error.
Could this be fixed in order to get a working and clear demo?
418:
<link rel="stylesheet" href="https://api.postcode.nl/static/<IP_ADDRESS>/css/autocomplete-address.css">
<script src="https://api.postcode.nl/static/<IP_ADDRESS>/js/PostcodeNl/AutocompleteAddress.min.js"></script>

Thanks for reporting this, it is resolved in the new release 1.0.4


Create a dedicated page for server configuration

It's better to set all the server settings from the dedicated page, not from the State Simulation page.

@nergal-perm the puzzle #56 is still not solved.

@nergal-perm the only puzzle #56 is solved here.


Building a simple bot scraper to extract prices data

Topic Suggestion
Nodejs
Writing sample(s):
https://www.section.io/engineering-education/building-a-simple-cryptocurrency-blockchain/
Proposed title of article
Building a simple bot scraper to extract prices data
Proposed article introduction
It's tedious to always for companies and developers to get prices for their products while trying to fit the market competition. Due to large data available online, it's easy for individuals and companies to hunt for prices and make huge bargain on there products by simply using web bot scraper.
Web scraping is the process of using bots to extract content and data from a website. This makes it easy to get large data than "copy" and "paste" which is time consuming.
In this tutorial, I'll explain using example how to build a simple bot to extract data that maybe use useful to enhance product competiveness in the world market using nodejs.
Key takeaways

Readers will understand web scraping use.
Readers will enhance their knowledge in nodejs to extract data in different platforms.
Readers will have ability to develop rea-time applications.

Article quality
This article will dive deep into web scraping using simple examples to the readers, we'll also explain some simple tools used over the world.
References

https://webscraper.io/
https://www.geeksforgeeks.org/what-is-web-scraping-and-how-to-use-it/

Thank you for the topic suggestion, however this is a bit outside of our preferred topic areas.
We're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts.
Please feel free to suggest an alternate topic to explore. 🚀