Creating a new survey

Hi,
Could you please help me? I'm trying to create a new survey, but I don't have any entity to use as example, could you share with me a print screen of your survey entity? remember I just need the properties...
Thank you in advance.

I think I'm right in saying you need to amend loaner/web_app/backend/lib/bootstrap.yaml
You will see the questions in there, and then I'm sure you will work out what to do.
You will have to bootstrap the build to clear the old questions though (I posted on the G+ group).
If you don't want to bootstrap then you will have to go into app engine and amend the questions in the live app - obviously you need to be careful.  You can't add extra questions though without bootstrapping, because the table changes, you can only change the text of the questions that are already there; I've done that and it works fine.

Hi Thank you for your answer!
I did the changes on bootstrap.yaml file (questions and emails template),
in constants.py  I have BOOTSTRAP_ENABLED = True, I have executed this
command:
bash deployments/deploy.sh web prod
After the process finish, I open the GnG web app:
https://gcp-grab-go.appspot.com/bootstrap
The tasks are performed:
[image: image.png]
But the survey is not updated, actually I cannot see the entity:
[image: image.png]
So I thought on create a new entity of the survey, do you think that this
could help?
Could you please send me a print screen of your entity of the survey,
please!
Thank you in advance for your help.
On Mon, Apr 29, 2019 at 3:40 PM templesnr<EMAIL_ADDRESS>wrote:

I think I'm right in saying you need to amend
loaner/web_app/backend/lib/bootstrap.yaml
You will see the questions in there, and then I'm sure you will work out
what to do.
You will have to bootstrap the build to clear the old questions though (I
posted on the G+ group).
If you don't want to bootstrap then you will have to go into app engine
and amend the questions in the live app - obviously you need to be careful.
You can't add extra questions though without bootstrapping, because the
table changes, you can only change the text of the questions that are
already there; I've done that and it works fine.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/loaner/issues/49#issuecomment-487735348, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKLPRKF5TNZ3GV7JFT47MITPS5MKDANCNFSM4HJGGWHA
.

--
Saludos.
Josue Sanchez

I can't see your images on your post.  It sounds like you did the right things. here is my entity screen, do you mean for question?

Hi!
Yes, I don't have that entities, could you open both and send me the
screenshot? I'm interested on the properties. Thank you in advance!!
On Mon, Apr 29, 2019 at 4:28 PM templesnr<EMAIL_ADDRESS>wrote:

I can't see your images on your post. It sounds like you did the right
things. here is my entity screen, do you mean for question?
[image: Screenshot_20190429_222551]
https://user-images.githubusercontent.com/44321380/56928147-dbcd1000-6acd-11e9-910f-57ddf27590a4.png
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/loaner/issues/49#issuecomment-487750675, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKLPRKHFE6UVNXJJOMCHA2LPS5R6NANCNFSM4HJGGWHA
.

--
Saludos.
Josue Sanchez

Hi "templesnr",
Could you please help me? I'm not seeing the 2 Question entities, I would like to add them manually but I need your help:

Please add 3 images:

showing the 2 question entities (all columns)
and 3) a full screenshot of the properties of each question entity

Thank you very much in advance.

I hope this helps:
id=9999999999999999 answers.more_info_enabled [false,true] answers.placeholder_text [null,"Please tell us about your experience..."] answers.text ["It was great!","I would like to give some feedback"] enabled true more_info_text null question_text How was your experience with the Grab 'n Go Chromebook? question_type 1 rand_weight 1 response null
id=9999999999999999 answers.more_info_enabled [false,false,false,true] answers.placeholder_text [null,null,null,"Tell us more..."] answers.text ["To attend a meeting in the office","To work away from my desk","To work from home","I would like to tell you why ..."] enabled true more_info_text null question_text Why are you borrowing the Grab 'n Go Chromebook today? question_type 0 rand_weight 1 response null

Sorry, but I did not understand the info, this is my first project on GCP, so I did not understand the structure of the entity... could you post and image, remove the header (namespace to URL-safe key), I just need the properties, thanks in advance.

Hi @JoshSanchezG - it is the expansion of the screen shot of the entities that I uploaded.  You can see the headings and then the content of the entity.
I wouldn't try to create the entities myself though they will be created during bootstrapping.
Maybe one of the developers could confirm whether or not it would be best to remove everything from AppEngine first?  Before trying to bootstrap with a new set of survey questions.
Can you confirm - did the survey entities exist when you first bootstrapped?
Do the entities still exist?

Hi,
First of all, thanks for your email. The Question entities were there,
unfortunately when I edited the emails templates and the surveys in the
web_app folder I got an error message and now the entities have gone. I
have tried bootstrapping the app but any change is applied, maybe someone
could tell me if I need to remove something in the GCP in order to build
the question entities with the bootstrap process.
Thanks for your help.
On Wed, May 1, 2019, 2:53 AM templesnr<EMAIL_ADDRESS>wrote:

Hi @JoshSanchezG https://github.com/JoshSanchezG - it is the expansion
of the screen shot of the entities that I uploaded. You can see the
headings and then the content of the entity.
I wouldn't try to create the entities myself though they will be created
during bootstrapping.
Maybe one of the developers could confirm whether or not it would be best
to remove everything from AppEngine first? Before trying to bootstrap with
a new set of survey questions.
Can you confirm - did the survey entities exist when you first
bootstrapped?
Do the entities still exist?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/loaner/issues/49#issuecomment-488229846, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKLPRKGYE5E5JHRBUQBOQDDPTFD6XANCNFSM4HJGGWHA
.

I tried to create the Question entities manually but it's not working and it was so difficult without an image of each one... it's a shame that nobody could help me with a simple image :(
I'm disappointing with this community...


Can scrcpy forward windows screen to android device?

Can scrcpy run on windows and then forward the screen to an android phone?

No, it's the other way around.


Expand Payload into larger view

Is your feature request related to a problem? Please describe.
Currently expanding the payload works great for small calls. However, for large calls (such as rpc. method calls) it can be difficult to navigate. Some method for expanding the payload into an even larger view should exist.
Describe the solution you'd like
Opening a new tab, or using a modal/popup could work well.

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on:

GitHub release
1.0.0

Your semantic-release bot :package::rocket:


qtstyleplugins: init at 2016-12-01, kdecoration-viewer: init at 2015-08-20

Motivation for this change
Add packages useful for Qt5/KDE5 developers and customizers.

qtstyleplugins bring back mostly classic widget styles, which are no more included into the main Qt5 repository.
kdecoration-viewer allows to preview kdecoration2 based decorations for KDE5.

Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @ttuegel


Make SRAM_INIT_FILE/ROM_INIT_FILE a parameter

We want to have multiple sram instances which have a different initialization file. Currently this initialization file name is passed as define, this needs to be a parameter instead.
First discussed in lowRISC/stwg-base#472

@imphil i think you've already resolved this issue, I'll close it down.


Create helpers for being a good citizen

creating releases with tags, verifying you have the github url in your hex description, ...

Maybe something like mix aspis.checklist that checks your mix.exs and the tags on your repo would be enough?

Still needs some nice checklist formatting with colours, checkmarks and information on what to do with missing points

Initial version done, closing. Related issue: https://github.com/nietaki/aspis/issues/11


JWT secret base64 encoded

OK, I am most probably doing something wrong, but I can't make a JWT token with HSA512 and base64 encoded secret that will validate against jwt.io
Any solution?

Can you send any error log ? So that anyone can look around .

Well, not much of a log on this level. But I tried to sign the token with:
	Secret := Babase64.URLEncoding.EncodeToString(secret)
	tokenString, _ := token.SignedString([]byte(Secret))

Just a simple test. I did more variations of this code and I was never able to get jwt.io to confirm that the token has a valid signature...

Any clues to what I am might be doing wrong?

Try removing any encoder padding. I encountered the same issue validating the example signature in RFC 7519.
b64Secret := base64.URLEncoding.WithPadding(base64.NoPadding).EncodeToString(secret)

This case can be closed. Well, guess what - it was a mistake on my end in a way. Or, rather, misunderstanding on how jwt.io works with them vs. the library...

This case can be closed. Well, guess what - it was a mistake on my end in a way. Or, rather, misunderstanding on how jwt.io works with them vs. the library...

@uded Hey thanks for creating this issue, could you please elaborate on what you found out regarding how jwt.io works vs the library ?

I was facing the same problem. After much trial and error I realized the correct understanding is that the "secret" is NOT base64 encoded when creating the token using this library in golang. When you test the generated token using jwt.io debugger, you can either enter your secret string or if you want to be extra sure that it is not leaked, you can encode your secret into a base64 string and then tick the checkbox indicating you entered an encoded string of your secret. Hope this info save someones time.


JSON-schema(-faker) support, mock data

Hello Dear Swaggers!
Recently I came upon the online swagger editor and I can see that the example definition reminds me of JSON schema, e.g.
      responses:
        '200':
          description: An array of products
          schema:
            type: array
            items:
              $ref: '#/definitions/Product'
        default:
          description: Unexpected error
          schema:
            $ref: '#/definitions/Error'

though it's in YAML instead of JSON.
My question is: have you been considering using JSON-Schema-faker to provide a way to define mock data for the API spec? JSON-Schema-faker is a superset of JSON Schema that defines how to generate semantic mock data. It's a specification + JS implementation. The benefit of combining those tools (swagger and json-schema-faker) together are:

online auto-generated docs could also generate example data structures (real JSON content)
standalone mock server for swagger data
and perhaps something more.

I can see that the sway repository by @whitlockjc is using json-schema-faker, but didn't manage to figure out what for yet.
I would appreciate any comments and ideas related to this topic.

sway provides mocks already using json-schema-faker.

Hi @whitlockjc, can you provide me an example on how this works? An online example maybe?
If json-schema-faker is used by sway, does it mean, it's part of the swagger spec or not? Is sway an official extension? Is entire swagger tool stack compatible with sway so that swagger users can make use of json-schema-faker?
I'm pretty new to swagger tool stack, forgive me naive questions...

json-schema-faker is just a data mocker... it's not a spec and is unrelated to Swagger directly. Supporting Swagger tools can use it, but that's pretty much as far as it goes.

Agreed.  Let's take this offline @ducin in the sway project.  Open an issue for an example but know there are tests that use it and there is API documentation.

Thanks @whitlockjc!


"drive_process_irp failed with error 13" when trying to write to a redirected folder

Files from a redirected folder can be read, but an attempt to copy a file to the redirected folder causes xfreerdp to terminate with following output.
FreeRDP is compiled from current master. The system is Ubuntu16.04.3 LTS. Build flags are: -DCMAKE_BUILD_TYPE=Release -DWITH_SSE2=ON -DWITH_JPEG=ON .
Command:
/usr/local/bin/xfreerdp /cert-ignore /bpp:32 /v:<IP_ADDRESS> /u:XXX /p:XXX /size:1920x1080
/client-hostname:Remote /drive:setup,/home/user/tsclient
Output:
[17:36:09:576] [26598:26599] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[17:36:09:576] [26598:26599] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[17:36:09:576] [26598:26599] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[17:36:12:836] [26598:26599] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[17:36:12:836] [26598:26599] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[17:36:12:898] [26598:26599] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem
[17:36:12:925] [26598:26604] [INFO][com.freerdp.channels.rdpdr.client] - Loading device service drive [setup] (static)
[17:36:14:032] [26598:26604] [INFO][com.freerdp.channels.rdpdr.client] - registered device #1: setup (type=8 id=1)
[17:36:15:618] [26598:26607] [ERROR][com.freerdp.channels.drive.client] - drive_process_irp failed with error 13!
[17:36:15:618] [26598:26599] [ERROR][com.freerdp.core] - drive_thread_func reported an error. Error was 13
[17:36:15:618] [26598:26599] [INFO][com.freerdp.client.x11] - Network disconnect!
[17:36:15:618] [26598:26599] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor

Same problem for me, I'm connecting to a windows 2003 server with the following commandline:
/v:servername /drive:doc,/home/giovanni/Documenti -grab-keyboard
When I try to copy a file to \tsclient\doc, xfreerdp exits logging the following:
[...]
[10:05:06:269] [18900:18917] [ERROR][com.freerdp.channels.drive.client] - drive_process_irp failed with error 13!
[10:05:06:269] [18900:18901] [ERROR][com.freerdp.core] - drive_thread_func reported an error. Error was 13
[10:05:06:269] [18900:18901] [INFO][com.freerdp.client.x11] - Network disconnect!
[10:05:06:269] [18900:18901] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor
[Thread 0x7fffdcbd5700 (LWP 18917) exited]
[...]

I have done some bisecting, and the bug seems to be here since commit b587daa (commit aa9ff84 did not show the problem).

@giox069 error 13 is ERROR_INVALID_DATA, could you put some breakpoints and find out which DR command is not parsed correctly (or is truly invalid) ?

I have no real idea of what I'm doing :), but this is an hexdump of the complete input stream (irp->input) received by drive_process_irp() and then drive_process_irp_create()
72 44 52 49 01 00 00 00 00 00 00 00 02 00 00 00
00 00 00 00 00 00 00 00 96 01 13 00 70 29 36 00
00 00 00 00 20 00 00 00 00 00 00 00 02 00 00 00
64 00 00 00 1A 00 00 00 5C 00 70 00 72 00 6F 00
63 00 65 00 78 00 70 00 2E 00 65 00 78 00 65 00
00 00

on enter of drive_process_irp_create() the stream pointer is at position 24 (dec), so process_irp_create() reads:
DesiredAccess = 00130196(hex)
allocationSize = 362970(hex)  this is exactly the file size
but remainingLengt of stream is only 46, which is less than allocationSize, so drive_process_irp_create() will fail with ERROR_INVALID_DATA
stream seems to be too short ?

@giox069 can you test https://github.com/FreeRDP/FreeRDP/pull/4162 ?

I did some file transfer test and PR #4162 worked fine (a bit slow, but I think this is common).
Very good!
I will do some other tests tomorrow if you need.

@hardening @giox069 we noticed recently the same thing especially when trying to copy PDF-files on the redirected folder .. instead of terminating it freezes the session.

The issue is fixed. Thank you!

Closing as fixed, reopen if this is not the case.


Help to developted azure python sdk.

Hi guys, how can i help with developing azure python sdk?
I work with sdk two weeks and i want help to developted this sdk.
Can i help?
About myself:
I am senior python developer from Russia, Moscow.
Work with python over 2 years, with MS .Net over 1.5 years.

Thanks!  We have big changes in progress (https://github.com/Azure/azure-sdk-for-python/issues/440), and we'll need help testing the new packages once they are on PyPI.  After that, we can look at our TODO list (and storage's) and see if there's anything you can help with!

Hi,
I will close this post since this is not exactly an issue, this does not mean that you can't help :)
Since the new SDK is now Auto-generated, the best way to help currently is testing, to allows us to cover every kind of scenarios. You can do a PR from your fork and we will discuss around that.
Thank you for your support!


Unicode vs. bytes in Python 3.x

I'm getting a TypeError when I try to list the accounts for my institution:
*** Python 3.4.5 |Anaconda 2.1.0 (64-bit)| (default, Jul  5 2016, 14:53:07) [MSC v.1600 64 bit (AMD64)] on win32. ***

>>> institution.accounts()
Traceback (most recent call last):
  File "<string>", line 301, in runcode
  File "<interactive input>", line 1, in <module>
  File "C:\Anaconda3\lib\site-packages\ofxclient\institution.py", line 143, in accounts
    parsed = OfxParser.parse(resp_handle)
  File "C:\Anaconda3\lib\site-packages\ofxparse\ofxparse.py", line 398, in parse
    ofx_file = OfxPreprocessedFile(file_handle)
  File "C:\Anaconda3\lib\site-packages\ofxparse\ofxparse.py", line 168, in __init__
    super(OfxPreprocessedFile, self).__init__(fh)
  File "C:\Anaconda3\lib\site-packages\ofxparse\ofxparse.py", line 98, in __init__
    self.read_headers()
  File "C:\Anaconda3\lib\site-packages\ofxparse\ofxparse.py", line 104, in read_headers
    head_data = head_data[:head_data.find(six.b('<'))]
TypeError: Can't convert 'bytes' object to str implicitly

I've ran into the same issue. Now trying in Python 2.7.

Ran into this as well. Removing the call to six.b() fixed it, but kept tripping over further conversion/encoding errors.

The issue is that ofxparse expects a "seekable file-like byte stream object".
See line 87, https://github.com/jseutter/ofxparse/blob/master/ofxparse/ofxparse.py
Ofxclient is providing a StreamIO object to ofxparse [StreamIO.StreamIO for Python 2, IO.StreamIO for Python3].
Ofxparse is apparently happy with the Python 2 StreamIO.StreamIO object, but is not happy with the Python3 IO.StreamIO.
However converting the IO.StreamIO object to an IO.BytesIO object fixes the issue.
For example, account.py, line 112:
change:
return OfxParser.parse(self.download(days=days))
to:
return OfxParser.parse(BytesIO(((self.download(days=days)).read()).encode()))
seems to work for Python3, assuming IO.BytesIO is imported.
I'll fork and request pull in the next few days.

Pull request #30 submitted to resolve this issue.


Environment variable expansion should allow default values

This is similar to the local dev/CI use-case in #46. It would be helpful to be able to provide default values for environment-variable configurations. So that the default is used normally, but the configuration can still be overridden locally without modifying the config file.

What would be the syntax that you'd suggest?

Not OP but came looking for the same thing:
${env:API_ENDPOINT:<IP_ADDRESS>}

would be my first guess/assumption that makes the most sense. In Java (maybe it's spring-specific) we use ${ENV_VAR_NAME:default_value} in our xml config. Since we are already prefixing with env: I think it stands to reason you add another : and shove your default value after that. It's not like many (if any) ENV vars are going to have a : in the name itself and if they do \-escaping seems logical.

Hi there, it's The Guild :) We're working on a new version of GraphQL Config. The goal is to make it platform agnostic, flexible enough to use with any tool and framework, reduce the bundle size and a lot more and what's even more important, bring it back to life and keep maintaining.
New changes #162 are already merged into master and v3.0.0-alpha.13 is released.
With new GraphQL Config you're able to use environment variables like this:
schema: ${MY_SCHEMA:schema.graphql}

Where MY_SCHEMA is the value coming from process.env.MY_SCHEMA and schema.graphql is a default value


envoy: Update to pick up fixes

Update Envoy image to pick up fixes:

reopen bpf ipcache map on network policy stream restart
Fixes the problem where cilium agent restart creates a new bpf ipcache map and (daemonset) cilium-envoy keeps using the old one.

change original destination cluster to not create different Host instances for the same destination
Fixes the problem where multiple Host instances are created when two worker threads access the same destination at the same time, and then one of them fails to create an upstream connection due to source port bind failure.

update Go dependencies
Fixes CVEs for the proxylib.

Fixes: #32651
Envoy now reopens ipcache on agent restart and avoids upstream bind errors on concurrent access to a destination.

/test


Remove clan from clan family

I am leader for clan Fatality #YR8UJ.  We briefly joined the Avalanche Family but it did not work out. We are no longer part of the clan family but our own independent clan.  However, we are still listed on royaleapi as part of Avalanche.  Can someone please help me remove Fatality? Thank you so much!

I just added RA8U to my clan description. Thank you so much for your help.

Thank you so much for the super fast response!


Updating sample code to use latest API versions

Purpose

Updated Speech REST API version to 3.1 and ConvesationAnalysis API version to 2022-10-01-preview.

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[x ] Other... Please describe: Updating API versions, no functional changes.

@trrwilson for review.

Looks great! Let's see if we can get the build to run...


React UI: Implement missing TSDB head stats section

See the discrepancy between https://demo.promlabs.com/status and https://demo.promlabs.com/new/tsdb-status, where the general row about head stats (min time, max time) is missing.
(also be sure to include the recently added https://github.com/prometheus/prometheus/pull/7544 in the new UI's head stats implementation)

I'm working on this one


"invalid json response body at https://api-1.adax.no/client-api/auth/token"

Describe The Bug:
There seems to be an issue with fetching the token from Adax API service. Everything should be in order in regards of client ID and password/secret.
Logs:
(node:1842) UnhandledPromiseRejectionWarning: FetchError: invalid json response body at https://api-1.adax.no/client-api/auth/token reason: Unexpected token < in JSON at position 0
at /usr/local/lib/node_modules/homebridge-adax/node_modules/node-fetch/lib/index.js:272:32
at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use node --trace-warnings ... to show where the warning was created)
(node:1842) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:1842) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Show the Homebridge logs here, remove any sensitive information.

**Plugin Config:**

```json
Show your Homebridge config.json here, remove any sensitive information.

Screenshots:

Environment:
Homebridge UI

@MaltefromFB You should be able to get a better error response now, let me know if that solves your issue


Fixes broken link

Self explanatory

@Nevskjij some before and after pics would help here. Was the lack of space preventing the url from rendering?

@joekiller Yes, exactly. The lack of space is making the clickable url send the user to the wrong page.


Beejones/key release policy operators

Before this change, the key release policy was only using an array of claims which needed to be found in the attestation.
The policy is extended with operators. We added two operators:
gt: Greater than indicating that the attestation claim must be greater than what is indicated in the policy.
gte: Greater than or equal.
The key release policy logic changed completely as also the constitution.
New unit tests check the logic of key release policy.

Tests:
https://github.com/microsoft/privacy-sandbox-dev/actions/runs/11036104516

new test:
https://github.com/microsoft/privacy-sandbox-dev/actions/runs/11067938914


Create 0000-01-02-null395922.md

layout: slide
title: "Welcome to our second slide!"
Your text
Use the left arrow to go back!


Validate more involved paths.

Currently defining a file with a name, for example, object1 then defining a file in that file (as if it were a directory, object1/filename) is permitted. This should not be allowed.

This is part of the restructure efforts.

Implemented in new iteration of codebase.


SXP10.3.2Update Releases Page

Description / Motivation

Add SXP10.3.2 Update new release directory page.

How Has This Been Tested?

Tested on localhost:3000

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[X] Documentation update (non-breaking change; modified files are limited to the /data directory or other markdown files)

Checklist:

[X] I have read the Contributing guide.
[X] My code/comments/docs fully adhere to the Code of Conduct.
[ ] My change is a code change.
[X] My change is a documentation change and there are NO other updates required.
[ ] My change has new or updated images which are stored in the /public/images folder that need to be migrated to Sitecore DAM

Not ready for publish. For internal release purposes only.

Closing this PR as not needed yet. Will redo later.


Nolan/formtesting

Added code using react-hook-form to handle initial user inputs (name, budget) and submitting data to the backend.

This pull request would remove some of the earlier polishing made to the FinalQuery component


Adding 'mdl-cell--6-col' (or other sizes) to a 'mdl-data-table' with 'mdl-data-table--selectable' causes the header selectable to be misaligned

If you try to set the width of a table using a size class such as 'mdl-cell--6-col' in a data table using the 'mdl-data-table--selectable' option, it causes the th header's checkbox to be misaligned. The issue appears to be due to td-based selectable checkboxes being position: absolute with left: 24px while the th selectable checkboxes have no such positioning.
See: https://jsfiddle.net/2jrwh45u/6/ (you'll need to resize the result window to be larger to see the th checkbox drift)

Good catch, thanks @cthielen! We'll try to get this in for 1.0.3.

Actually, closing this one as it seems to be a duplicate of #923. Let's track this there.


Use Ramda for functional point free programming

This is already written in a mostly functional style, a Ramda refactor would be nice for maintenance and testing.

After refactoring it's so much simpler that we no longer need Ramda, at least for now. Ramda also seems to be missing curried versions of some of the RegExp functions we use.


Get the sonnet.library working on the 1200TX mediator

At the moment, the sonnet.library only supports the A3000Di mediator. This is a mediator which has the needed 3.3V line. The only other mediator which has the 3.3V line (and with a much larger userbase) is the mediator TX (when connected to an ATX PSU).
The current state is that the PPC is initialized by the sonnet library. It sets up its memory and communicates this with the 68K. The 68K however cannot properly address the sonnet memory. This is probably due to the Z2 window.
I suspect there are functions inside the pci.library to fix this. The memory of the sonnet should be initiated the same way as graphics memory (using the pci.library) and the relevant pci.library functions will probably contain MMU code.
I will investigate this further.

Got some first results. Using the default MMU window of $80000000-$A0000000 did the trick. See http://amigafun.blogspot.nl/2015/12/picture-of-day-dualppc.html

Congrats on that, I saw the code, looks good to me. I really need to put back my A1200T together, now that I can test Sonnet with it.

A (number of) function(s) appear(s) to be broken on the 1200TX. The only other program I tried didn't work (Quake2)  It exits gracefully complaining about the soft_rend.dll not being available. It loads fine, however. I also see that the main program probes for a certain 68K port. I expect Run68K to be broken. Looking into it.

Investigation into the problem is hindered by debug tools not correctly working in the environment created by the PCI library. Monam crashes and COP cannot read the gfx or sonnet memory (put into place using the MMU by the pci.library).
Next to that some strange stuff is happening. The CyberPI program for example only outputs the pi result. The actual text before and after are not displayed. This is actually 68K code (Output() and Write()) called from the 68K part of the CyberPI program indicating that 68K lib function calling from gfx or sonnet mem is impaired, probably in combination with Z2 window shifting.
I don't think we'll see a working Sonnet card on the A1200 this year.

At the moment writing my own MMU setup code to replace the one in pci.library. Chopping up the 512MB from $80000000-$A0000000 in 8MB pieces. Every 8MB piece will point to the Z2 memory of $200000-$A00000. Only one 8MB will be marked valid, though The rest will be marked invalid. An access to an invalid 8MB piece will invoke the bus error handler. Inside this handler we'll shift the Z2 window and mark the new 8MB piece valid and the old one invalid. Will be using indirect page descriptors for VERY fast MMU switching. Both supervisor and user MMU trees must be addressed.
In theory, this all sounds good, but I don't know yet if this will interfere with the workings of the pci.library. Even with MMU=no as option the pci.library still installs a bus error hook on the A1200, probably to catch PCI memory accesses. I'm optimistic, though :-)

I wonder, would it be possible to use mmu.library for this? It is still actively developed and seems to be the standard system-friendly way for manipulating the MMU.
http://aminet.net/package/util/libs/MMULib

Also note that you should support 4MB pieces too, after all Mediator 1200 can be switched into 4MB window mode by jumper.

Yes, I am using the mmu.library for this. Maybe pester the author about be able to set multiple indirect pages at once. I now have to do a Setproperties call for every page (4k...and that for 512MB)... Only during setup, though.
The 4MB support will follow if this works for the 8MB window

As I understand, @thorfdbg is the author of mmu.library, maybe he can comment here and give his opinion, since he has an account on GitHub :wink: .

Oh, well, I've send him a mail already :-) It's a nice-to-have really as I can just program a loop. It is needed during setup only but it will shorten the setup time. Most setup time is already going in setting up the PPC MMU.

Am 01.02.2016 um 13:06 schrieb Radosław Kujawa:

As I understand, @thorfdbg https://github.com/thorfdbg is the author
of |mmu.library|, maybe he can comment here and give his opinion, since
he has an account on GitHub :wink: .

It's probably easier just to mail to this account. Not sure whether
github will reach me. But yes, thorfdbg is my github account.
Greetings,
Thomas

Hello Thomas,
Thank you for your answer. I was under the impression that using the
INDIRECT approach was faster than the SINGLE approach.
I was also under the impression for SetIndirectArray to work, you have to
install the pages first using SetProperties. As INDIRECT only takes one
DESCRIPTOR I need to call it for all the pages during setup. There is no
magic code inside SetProperties which updates the DESCRIPTOR per page used
when size > 1 page.
I think I know enough to first try this all with the INDIRECT approach. I
just need to call the SetProperties function 131071 times :-)
Let's see how that goes. Otherwise I'll do the single approach.
I see that the docs don't explain what 'lower' (a1) is for
SetPageProperties.
The end goal is to make PCI memory access seem transparent to programs on
the Mediator 1200TX. The whole 32bit range can only be accessed using a
sliding windows residing at $200000. In effect, I need to replace a similar
function now executed within the pci.library but which is buggy and not
friendly to other programs using the MMU.
Thanks again,
Dennis.

I am developing a library which needs to redirect memory calls from a
512MB block starting from $80000000 to Zorro 2 memory space. So I want
to point multiple blocks of 8MB inside that 512MB block to one 8MB block
at $200000.
I want to do this with MAPP_INDIRECT as I need to change the properties
of those 8MB blocks quickly. (One of them is valid, the rest will be
invalid. If invalid, bus error is handled -> mediator window is set on
invalid block -> block is made valid -> Previous 8MB block is made
invalid -> rte).

That's one possibility. MAPP_INDIRECT has one drawback, however, and
that is that the page modes cannot and will not be automatically
adjusted when a DMA transfer is running from such pages. A better
alternative is usually to map the pages as MAPP_SINGLE, which creates a
single descriptor per page, i.e. it disables the early termination page
descriptors (for the 030 and the 581, of course).
Then, you can rather quickly change the modes by SetPageProperties().
There is one drawback, however, namely that your properties will be
overwritten as soon as the MMU table in this area is rewritten, so it's
usually best to setup the high-level page propertes with SetProperties()
to something useful, and then alter the page properties one by one.
SetPageProperties is pretty quick and goes directly on the page
descriptor, by a per-CPU type dispatcher that avoids CPU-dependencies.
If this is not acceptable, you can also install a page-table access
handler with
AddContextHook(MADTAG_TYPE,MMUEH_PAGEACCESS,...)
and you will be called as soon as the high-level function leaks through
to the low-level and changes a setting there. That's the strategy
MuGuardianAngel works, namely by quickly changing the page access to
INVALID to those pages that should not be reached because they only
contain free memory.
In case you want to recover from page faults, you should also set
MAPP_REPAIRABLE. It tells the bus-error handler to collect additional
information for you that is otherwise not available.

Is it correct I can only set 1 page at the time with INDIRECT and
MAPTAG_DESCRIPTOR? using SetProperties? I would like it that when I set
logical address and size that when I set size at 8MB that it increases
MAPTAG_DESCRIPTOR by 4 (or 16, depending on tag or flag?) for every page
(so for like 8MB/4k pages) so I don't need to call SetProperties for
every page during setup (=8MB/4k calls).

MAPP_INDIRECT works also on larger page sets, though it then acts
similar to MAPP_BUNDLED, i.e. the entire page block will go to the same
(single) descriptor. The Lib does not try to "smartly" adjust the
position of the indirect descriptor.
If you need to adjust an entire array, you have to use...

I want to use SetIndirectArray in the bus error hook.

..exactly that. (-: It's a low-level function, i.e. on the same level as
SetPageProperties().

Or is this already possible and did I overlook it in the documents? Or
is there another method of quickly just mark pages invalid/valid.

As suggested above, I would go for SetPageProperties() which is usually
the safer way of getting it done. However, not knowing your constraints
and design goals, it's a bit hard to answer.
2016-02-01 19:55 GMT+01:00 Thomas Richter<EMAIL_ADDRESS>
Am 01.02.2016 um 13:06 schrieb Radosław Kujawa:

As I understand, @thorfdbg https://github.com/thorfdbg is the author
of |mmu.library|, maybe he can comment here and give his opinion, since
he has an account on GitHub :wink: .

It's probably easier just to mail to this account. Not sure whether
github will reach me. But yes, thorfdbg is my github account.
Greetings,
Thomas
—
Reply to this email directly or view it on GitHub
https://github.com/Sakura-IT/SonnetAmiga/issues/21#issuecomment-178128622
.

Am 01.02.2016 um 20:17 schrieb DvdBoon:

Hello Thomas,
Thank you for your answer. I was under the impression that using the
INDIRECT approach was faster than the SINGLE approach.

The question is "how fast" is "fast enough". It would probably be
helpful to know what you are attempting and what the expected latency
is. So for example, how often do you need to adjust pages?
SetPageProperties is not overly slow (unlike the high-level functions).
 If so, then
indirect descriptors will cause trouble.

I was also under the impression for SetIndirectArray to work, you have to
install the pages first using SetProperties.

Yes, as always. You need to set the MAPP_INDIRECT flag for that.

As INDIRECT only takes one
DESCRIPTOR I need to call it for all the pages during setup. There is no
magic code inside SetProperties which updates the DESCRIPTOR per page used
when size > 1 page.

It will always point to the same descriptor for all papges in the area,
this is correct.

I think I know enough to first try this all with the INDIRECT approach. I
just need to call the SetProperties function 131071 times :-)

Not necessarily. You can also first set the pages to point all to the
same indirect page and then call SetPagePropertiesA() to adjust the
pointer. MAPTAG_DESCRIPTOR is the tag that defines the target descriptor.

Let's see how that goes. Otherwise I'll do the single approach.
I see that the docs don't explain what 'lower' (a1) is for
SetPageProperties.

Its the logical address for which the mapping has to be modified.

The end goal is to make PCI memory access seem transparent to programs on
the Mediator 1200TX. The whole 32bit range can only be accessed using a
sliding windows residing at $200000. In effect, I need to replace a similar
function now executed within the pci.library but which is buggy and not
friendly to other programs using the MMU.

I see. So in essence, a write into the PCI area (logical address) has to
be remapped to go into the window at $200000 instead, and for every
potential PCI access you have to perform a remap? However, how do you
decide which window of the PCI memory to map in? And, forgive me the
silly question, why is the memory not accessed in the window directly
with its hardware address, thus why the back-and-forth of physical and
logical mapping? After all, a program can only access a single PCI
device at a time due to windowing in first place, do I get this right?
If I may: It is probably easier not to use descriptors in first place.
The library can give you accesso the CPU pipeline, i.e. you can get
accss to the data the code has written, and the data the code has just
read. You can define an exception hook that picks up the data that has
just been written, its size, and perform the transfer to the target
address within the window manually.
The downside is that this does not work for movem, i.e. it can only
catch up byte, word or long-word reads or writes.
If nothing helps, I can probably add another flag to SetPageProperties()
to have "non-bundled" indirect descriptor setup, though this might take
a while until I have an implementation.
Let me know how it goes and whether I can do something for you to
support you further.
Greetings,
Thomas

Hello,
2016-02-01 21:04 GMT+01:00 Thomas Richter<EMAIL_ADDRESS>
Am 01.02.2016 um 20:17 schrieb DvdBoon:

I see. So in essence, a write into the PCI area (logical address) has to
be remapped to go into the window at $200000 instead, and for every

For every access, that is correct.

potential PCI access you have to perform a remap? However, how do you

I need to do a remap if the access is outside the current 8MB window. The
Mediator can hardware remap/mirror an 8MB window of PCI memory to $200000
No remap is needed if concurrent accesses are within this window. As soon
as there is an access outside this window, I need to remap.

decide which window of the PCI memory to map in? And, forgive me the

By looking at the upper bits of the logical address. These bits are used to
move the Mediator hardware remap window to the correct PCI 32 bit address.
Then I need to remap the PCI addresses to this window at $200000 using the
68K MMU.
Example:
If I access $80000000. The mediator window need to move to this address so
the window at $200000 is reflecting PCI memory at $80000000-$80800000 (it's
how the mediator works)
Then I remap, using the MMU, access to $80000000-$80800000 to
$200000-$a00000. Every access within $80000000-$80800000 is now
transparently handled.
Then an access to $90000000 happens. Then I need to configure the mediator
to show/mirror $90000000-$90800000 at the $200000 window and tell the MMU
to translate these addresses to $200000
All this needs to be as fast as possible. I hope I'm a bit clear :-)

silly question, why is the memory not accessed in the window directly
with its hardware address, thus why the back-and-forth of physical and
logical mapping? After all, a program can only access a single PCI
device at a time due to windowing in first place, do I get this right?

I need to run 68K code from within PCI memory. As Amiga code is mostly
small, I don't expect a lot of switching of the MMU and Mediator window,
but that's why I need it to be as fast as possible.

If I may: It is probably easier not to use descriptors in first place.
The library can give you accesso the CPU pipeline, i.e. you can get
accss to the data the code has written, and the data the code has just
read. You can define an exception hook that picks up the data that has
just been written, its size, and perform the transfer to the target
address within the window manually.
The downside is that this does not work for movem, i.e. it can only
catch up byte, word or long-word reads or writes.

I need to run code inside the PCI memory. I think the above method is
indeed the best if you just shovel data around.

If nothing helps, I can probably add another flag to SetPageProperties()
to have "non-bundled" indirect descriptor setup, though this might take
a while until I have an implementation.
Let me know how it goes and whether I can do something for you to
support you further.

I will, thanks for all your comments so far!

Greetings,
Thomas
—
Reply to this email directly or view it on GitHub
https://github.com/Sakura-IT/SonnetAmiga/issues/21#issuecomment-178164062
.

Using loads and loads of indirect pages using 1 page at the time with SetProperties takes too long, unfortunately (each access to SetProperties becomes slower and slower for every new page added).
I am guessing doing a range using SetProperties is MUCH more efficient. I still like the indirect approach a lot. Maybe just set up with a single indirect page descriptor using the mmu.library and then adjust the table with all the needed indirect page descriptors outside of the mmu.library.

Looking at the documentation of 040/060 it is maybe easier to just do a normal remapped for each 8 MB block. Set them all invalid except for the initial one and just change the 16 pointer level table descriptors which make up the 8MB blocks to mark them either valid or invalid when needed.
I think i see the mmu.library does not (directly) support modification of tables.
Probably won't work on other MMU's

If you want my opinion, I think doing anything that would rule out 68030 usage is not very wise. 68030 is still hugely popular with Mediator owners (include me...). Maybe we could have separate methods of solving this problem for 68030 and 68040/68060.
I have to admit I just don't know enough about 68k MMUs to be of any help here. I only dug a bit in NetBSD's 68k MMU code but it is very complex (over 66kB) and in NetBSD every process is living in a separate virtual address space - it's a design completely different than AmigaOS.
Again, maybe @thorfdbg can add the necessary functions to mmu.library, since in one of the above comments he expressed the will to help with this.
I'd prefer to avoid messing with the MMU directly, I'm 100% sure that would cause further problems. Note that some people already have mmu.library installations, anything we do here would create a conflict. Additionally, various CPU-board specific libraries mess with the MMU (68040.library etc.), that's why mmu.library is providing own implementation of CPU libraries...

On 01.02.2016 22:29, DvdBoon wrote:

Using loads and loads of indirect pages using 1 page at the time with
SetProperties takes too long, unfortunately (each access to
SetProperties becomes slower and slower for every new page added).

Try to setup the properties in inverse order, i.e. start with the
highest page. This should give you linear performance instead of
quadratic running time.

I am guessing doing a range using SetProperties is MUCH more efficient.
I still like the indirect approach a lot. Maybe just set up with a
single indirect page descriptor using the mmu.library and then adjust
the table with all the needed indirect page descriptors outside of the
mmu.library.

I believe I still have to think of a good design for all this. The
current design is not exactly suitable for the use case you have. There
are a couple of issues, however: First, you cannot really control the
page size(s), that's up to the environment to select, and also hardware
dependent. Thus, even if I give you access to a higher level in the page
table, it is still unclear whether the page size is sufficient for you.
Or whether such a descriptor level exists in first place. The
Apollo/Vampire core will probably only have a linear (one-level) page
addressing model, so there will be no higher level at all.
Second, what happens if a context switch occurs and the tables are
exchanged. I need to carry modifications over. In principle possible if
you administrate the level yourself.
Third, what happens on DMA transfer. I need to cache-inhibit the
boundary pages due to the Amiga bus design, so one way or another the
library needs to know where your pages are and how to modify them.
Last, how to handle top-level modifications of the page layout.
I do not have an immediate answer to these questions at this point, and
coming up with a good design will probably take a while - even more so
as I'm busy with a lot of other things.
But anyhow, thanks for looking into this. I'm confident we'll come up
with something, even though it might probably take a bit longer than you
might have planned - sorry for that.
Greetings,
Thomas

All the help is appreciated :-). In the end, the only thing I really want is that I get notified when an access occurs outside the current Mediator window (being 8MB or 4MB depending on jumper) so I can slide this Mediator window to reflect the correct PCI memory range.
I constrain this to only PCI memory addresses $80000000-$A0000000 to make life easier. 512MB should be enough for now.
You say something about page sizes? I don't want to control them. I just noticed that I can also mark the pointer tables as being invalid. As I see it, there are 128 root tables controlling 32MB each (which is too big) the next level are pointer tables which control 128kb each. So I need to mark 32 (not 16, I miscalculated...) pointer tables as invalid to invalidate all the pages in the next level (at least on the 040. I assume that the 060 is the same. Don't know about 030). Also assuming a page size of 4k, Haven't looked what happens at a size of 8k.
Or am I wrong here?
I'll try the reverse addressing you mentioned first to stay mmu.library compliant.

As an addition: (if the reverse addressing does not work)
So I am thinking about doing 64 (in the case of 8MB) remaps of 8MB each with every one pointing to $200000 and marked as being valid. The level above it (the 32 table pointers for each 8MB window) I'll mark as invalid.
When a hit occurs, I set the correct window (setting the (U)DT bits) on valid and slide the mediator window to the correct PCI memory address. The window we slide away from we mark as invalid.
No need to use INDIRECT. Just need access to the pointer tables.

On 02.02.2016 10:44, DvdBoon wrote:

As an addition: (if the reverse addressing does not work)
So I am thinking about doing 64 (in the case of 8MB) remaps of 8MB each
with every one pointing to $200000 and marked as being valid. The level
above it (the 32 table pointers for each 8MB window) I'll mark as invalid.
When a hit occurs, I set the correct window (setting the (U)DT bits) on
valid and slide the mediator window to the correct PCI memory address.
The window we slide away from we mark as invalid.
No need to use INDIRECT. Just need access to the pointer tables.

Which you don't. (-: The problem is really that I cannot even ensure
that there are pointer tables in first place. The current abstraction
is really a list of pages, not a tree, and it might really happen that
the MMU table is not a tree at all. As said, I need to think about it
how to abstract this and come back to you.
Greetings,
Thomas

For my information, you mean that on the mmu.library level, there is no tree just a list of pages? Ok, I get it now, I think :-) I could set it all up using the mmu.library and then directly poke at the pointer tables using the hardware, but with an outside rebuildtree everything gets lost.
I'll come back to here when I tried the INDIRECT approach with starting at the top of the address range.

Setting the properties in reverse order worked. Only the RebuildTree takes forever now.

Am 02.02.2016 um 11:14 schrieb DvdBoon:

I'll come back to here when I tried the INDIRECT approach with starting
at the top of the address range.

As a related question: How large is the window you want to map in? Does
it change in size? And how many different configurations would you need
to support?
Thanks,
Thomas

The Mediator 1200 window into PCI memory space is 4MB or 8MB, depending on hardware configuration (a jumper, actually). The size does not change.
If you want I can give you a detailed description how does it work.

I like to map 64 8 MB windows or 128 4 MB windows to 1 static 8 or 4 MB window. If all windows are in place just switching on and off (valid/invalid) would be the fastest, I think.
OR
I like to map 1 8 MB window or 1 4 MB window to 1 static 8 MB or 4 MB window if creating and destroying a single remap on the fly is fast enough. In this case the whole 512 MB is invalid except for the 8 or 4 MB remap which is created on the fly. The previous one is destroyed (made invalid again).
These 8 MB or 4 MB windows are on a 8 or 4 MB boundary starting from $80000000 up to $A0000000
The static window is $200000-$A00000 (Mediator Z2/PCI memory window, can also be $200000-$600000 in case of 4 MB)..
The window size is determined at power up (using a jumper on the mediator) and does not change during operation.
Extra info as to why the 512 MB:
512 MB is wanted as to address 256 MB of Radeon GFX memory and 128 MB Sonnet 7200 memory (or 128 Radeon / 256 Sonnet or 32 Voodoo / 256 Sonnet etc etc). These must be on their own 256 MB and 128 MB etc boundary so actually at least 128 MB is wasted. (small part in use by PCI config registers). This gfx/sonnet memory (~360 MB) has to hold PPC and 68K code.
So for example:
$80000000-xxx PCI config space (BARs etc). not much else, mostly within the first 128k
$88000000-$90000000 Sonnet memory 128 MB
$90000000-$A0000000 Radeon Gfx 256 MB

Am 02.02.2016 um 22:34 schrieb Radosław Kujawa:

The Mediator 1200 window into PCI memory space is 4MB or 8MB, depending
on hardware configuration (a jumper, actually). The size does not change.
If you want I can give you a detailed description how does it work.

I believe I understand how it works. I'm just trying to get the
operating parameters straight to come up with a useful design for it.
Part of the problem is that you would need to do the switch under
uncontrolled conditions. The mmu.library can catch an invalid access
just fine, and react on that by calling user level code to perform some
action on that. The call into user code from the bus error recovery is
completely transparent and does not require any higher level Os magic.
However, most high-level mmulib interface functions use semaphore
locking to be thread (or rather "task"-)safe. That is not a problem -
the problem is that a task that runs into a semaphore will necessarily
break the Forbid() or Disable() state of exec (naturally, what else can
it do), and this implies that the task that tried to make the invalid
page access, and fixing that by a higher level accessor function would
potentially need to be halted because some other task is working on the
mmu tables at the very same time. And this "halting" might potentially
break a protocol the first task is implementing.
IOWs, the only chance to get the page swap done is by low-level
functions, and that's the part which is a bit "touchy" because there is
no abstraction of "page level" in the library, and because high-level
definiions can overwrite low-level definitions at any time. (And there
cannot be a page-level abstraction because it is quite likely that some
future extensions or developments will not have a tree-based MMU).
Greetings,
Thomas

@DvdBoon
I'd highly suggest to use method discussed in this thread to access PCI memory space only. Remember that the window within Z2 memory space (0x20000-0xA00000) is only for accessing the PCI memory space.
To access the PCI configuration space through this MMU mapping, we'd also need to mess with the second Mediator board, the one within Z2 I/O space.  This board is internally divided into two 64kB spaces. However, the first 64kB is used to access Mediator bridge setup registers. The second 64kB space is shared between PCI configuration and PCI I/O space. Whether you see config space or I/O space there depends on register at offset 0x7 within the bridge setup space.
Long story short, it would make things even more complex. I'm afraid touching it will create further problems, as only pci.library knows the current state of this area.
On a side note, I really should write an article about low level Mediator programming...

I think I made things confusing with saying config space. I meant special registers set up by the PCI BARs like the configuration block (EUMB) of the Sonnet which is placed in PCI memory (MEMSPACE, ROMSPACE), not config memory (IOSPACE).
Anyway, I don't need to mess with that if the pci.library is running and sets it all up.

Question @rkujawa
0xAddress >> 0x10 & 0xFF80 = value to store at $EA0002 to slide window (byte-swapped)
But if I read $EA0002 I see a value 0x2f90. which gives after byte-swapping 0x902f. This value is not 8 MB or 4 MB aligned. pci.library does not do & 0xFF80 (or & 0xFFC0 for 4 MB)? Or do I also need to AND again after reading and byteswapping?

0xAddress >> 0x10 & 0xFF80 = value to store at $EA0002 to slide window (byte-swapped)

That's what I did in the Mediator 1200 NetBSD driver and it worked, but...

But if I read $EA0002 I see a value 0x2f90. which gives after byte-swapping 0x902f. This value is not 8 MB or 4 MB aligned. pci.library does not do & 0xFF80 (or & 0xFFC0 for 4 MB)?

To be honest, I reverse engineered pci.library back in 2012 and I don't remember now what does it exactly do. I suspect two possibilities:

Mediator doesn't actually need an aligned address in the window register. Unlikely but possible...

This register is probably not supposed to be read, or if it does, you should AND the result with 0xFF80/0xFFC0? I'd guess it represents a state of all PCI address lines not connected directly to the window area. So only highest 9 bits of PCI address are in fact connected to this register (in case of 8MB window), bit 23-31. Of course they are stored in 16-bit register, so became bits 7-15. But do the low bits 0-5 have any meaning? I don't know.

Or do I also need to AND again after reading and byteswapping?

Most likely, but you should probably do some experiments with cleanly booted system (i.e. no pci.library running). Write some values to this register, read them back, see what you get.

I hope to have some proof of concept code ready later this evening just to test whether this approach will work. It is a hybrid now of using the mmu.library (detecting mmu type, page-size, setting up the MMU, adding an segfault handler and activating it) and direct poking in the table-pointers to set stuff invalid/valid very quickly (bit 1 of the UDT bits).
Preliminary test are promising so far. Haven't written a complete segfault handler yet, but the set-up is complete.
If the pci.library does not do 4 MB/8 MB alignment I also need to take over the gfx window handling by the pci.library (getting a step closer to eliminating its use altogether almost).
I hope that it will be 100% mmu library compliant in the future. For now, I probably need a hook on RebuildTree to detect tree rebuilds which will reset the UDT bits probably.

Am 03.02.2016 um 13:16 schrieb DvdBoon:

I hope to have some proof of concept code ready later this evening just
to test whether this approach will work. It is a hybrid now of using the
mmu.library (detecting mmu type, page-size, setting up the MMU, adding
an segfault handler and activating it) and direct poking in the
table-pointers to set stuff invalid/valid very quickly (bit 1 of the UDT
bits).

Please don't do that. It might seem to work, but it will not, and it
will cause a lot of problems. The bottom page table layout of a
mmu.library generated mmu table is more than just the table
descriptors. If you allocate your page table yourself, the additional
information the mmu.library keeps at the page level is not there, and
hence the library will overwrite innocent memory.
Just to let you know what is there in addition:
*) The page level contains for each page a DMA cache disable counter.
This counter is incremented each time a DMA transfer is initiated, and
then causes the corresponding page to go into cache-inhibit. (more or
less). It is decremented when the page goes out of DMA. If the counter
reaches zero, the original cache state is restored.
*) The page level also includes (besides the native MMU descriptor)
the abstract descriptor you read by GetPagePropertiesA(). This abstract
descriptor also keeps the cache state the page should have according
to the library, but which it cannot have due to pending DMA transfers.
*) An additional user-pointer that can be deployed for any type of VM
application.
So, in other words: No, you cannot simply replace branches of the MMU
table with your own branches and hope this works. It will not.
Please do not attempt this.
How exactly the page table is populated and where this information is
stored is an implementation detail. It is not documented, and might
change at any time.
As said, I need to come up with a design for your problem, but replacing
table pointers does not work.
Greetings,
Thomas

In short, as I am on the move: I am not replacing table pointers, I set
them up using the mmu library as valid and then directly (using urp, srp)
toggle a bit in the udt to mark all, except one window as invalid. But for
now I guess I give it a rest :-)
Op 3 feb. 2016 14:10 schreef "Thomas Richter"<EMAIL_ADDRESS>
Am 03.02.2016 um 13:16 schrieb DvdBoon:

I hope to have some proof of concept code ready later this evening just
to test whether this approach will work. It is a hybrid now of using the
mmu.library (detecting mmu type, page-size, setting up the MMU, adding
an segfault handler and activating it) and direct poking in the
table-pointers to set stuff invalid/valid very quickly (bit 1 of the UDT
bits).

Please don't do that. It might seem to work, but it will not, and it
will cause a lot of problems. The bottom page table layout of a
mmu.library generated mmu table is more than just the table
descriptors. If you allocate your page table yourself, the additional
information the mmu.library keeps at the page level is not there, and
hence the library will overwrite innocent memory.
Just to let you know what is there in addition:
*) The page level contains for each page a DMA cache disable counter.
This counter is incremented each time a DMA transfer is initiated, and
then causes the corresponding page to go into cache-inhibit. (more or
less). It is decremented when the page goes out of DMA. If the counter
reaches zero, the original cache state is restored.
*) The page level also includes (besides the native MMU descriptor)
the abstract descriptor you read by GetPagePropertiesA(). This abstract
descriptor also keeps the cache state the page should have according
to the library, but which it cannot have due to pending DMA transfers.
*) An additional user-pointer that can be deployed for any type of VM
application.
So, in other words: No, you cannot simply replace branches of the MMU
table with your own branches and hope this works. It will not.
Please do not attempt this.
How exactly the page table is populated and where this information is
stored is an implementation detail. It is not documented, and might
change at any time.
As said, I need to come up with a design for your problem, but replacing
table pointers does not work.
Greetings,
Thomas
—
Reply to this email directly or view it on GitHub
https://github.com/Sakura-IT/SonnetAmiga/issues/21#issuecomment-179221430
.

I meant I build the whole tree using mmu library with the PAGES as being valid and toggle bits in the TABLE POINTERS (a level above the pages). But directly IN the tree.
Just to make things clear (I hope).

Am 03.02.2016 um 15:31 schrieb DvdBoon:

I meant I build the whole tree using mmu library with the PAGES as being
valid and toggle bits in the TABLE POINTERS (a level above the pages).
But directly IN the tree.

Yes, same problem. The page level needs to be build by the library or
you're going to be in deep trouble. A "quick and dirty trick"(tm) would
be to create not one context, but eight MMU contexts and exchange their
upper level pointers between the contexts. This still does not keep the
upper and the lower abstraction level in sync, but at least it gives the
library a valid MMU table to allow switching.
Allocating parts of the MMU table itself is a bad idea(tm) as I
already said.
Anyhow, I don't see the need for any rush at this point, so I would
avoid any hacky approach at all. There need to be a solution that is
cleanly integrated into the overall design and not a work-around.
Greetings,
Thomas

Anyhow, I don't see the need for any rush at this point, so I would
avoid any hacky approach at all.

Agreed about that, we already have enough hacks and workarounds.

Hey @thorfdbg did you think of a clean solution that could be implemented using mmu.library? A month has passed and the discussion has kind of stalled ;).

Had a quick look today and more complications. As the mediator as a default puts the extra memory >$8000000 some of the WarpOS programs fail in general. For example, CyberPi loads an address to be used in a DOS Write() and does a bmi check. This branch will always be taken now and nothing is printed when the string is in an area >$80000000

Hi folks,
no, I haven't forgotten you. I'm unfortunately just very busy these days
and have only rarely enough time to work on the Amiga.
So yes, I did some work on the mmu.library and I believe that I have now
a design that might work. At this time, it is only implemented, not
tested. I will do some elementary tests this and next week, though
development may continue at the same glacial speed it did in the past -
sorry again for this.
So here is how it will work:

Build N additional MMU contexts where each defines the physical to
logical mapping for the memory window of the Mediator target window(s).

Reserve an additional four byte (one long word) pointer that will
keep the active window. Set this to NULL initially. This is a
"MMUContext **".

In the default MMU context, mark the range into which the windows
will appear as MAPP_WINDOW. This will be a MMU property flag in the next
version. Additionally, one tag has to be set to the pointer above to
identify the window (there can be an arbitary number of windows and this
pointer identifies the window).

Call "RebuildTree()". This will build a new MMU tree with the
"window" area as invalid.

When you need to change the memory layout, install one of the N
additional contexts with MapWindow(). This call is interrupt and
supervisor-callable. So you probably want to install a page access
handler in the default context that registers the access and then calls,
as reaction MapWindow().

There are a couple of restrictions, though. The additional contexts and
the mapping of the default context must "fit" together to make this
possible, i.e. the separation of the contexts into "nodes" must be the
same, at the same addresses. This is something I probably still have to
think about.
I neither know whether "MapWindow" will be fast enough. It is not
exactly a long function, but it might be possible to come up with an
additional call that pre-computes some of the internal values and stores
them in an opaque structure for easier and faster reuse.
DMA transfers, however, will interact fine even when the mapping
changes, so the system remains consistent. The system should hence
interact nicely with the rest of the MMU system.
I'll probably think about the quirks again, and it will still take a
while until I'll have a workable version for testing, and probably a
demo, but I'll just want to let you know where I am, approximately, and
give you a chance to give some feedback on this if this design does not
fit with your application.
Happy Easter!
Greetings,
Thomas

Happy Easter Thomas!
Thanks for the update. Speed indeed will be crucial in the end. I am still suspecting that the Mediator 8MB window can be split in 2x4MB with 1 keeping it on the gfx memory, because when I am in COP i can read the addresses (after envi.m) at $80000000 (default window) and at $90000000 (gfx memory) but not let's say $88000000. It would make things a bit easier. (COP is the only mmu program to work when mmu=yes for mediator on my system).
As said, one of the things I thought were the result of pci.library/sonnet.library not working properly was actually an artifact of the code/data being in the negative (if you look at them as signed values) address range (>$80000000) I'm not sure how this affects some of the other WarpOS programs. I have to look further into this. I rather use the, let's say $40000000-$60000000 range.
Focus on my side is to get the virtual signal pool going (PPC and 68K sharing the same signals) before I shift my attention back to the A1200 (I've contacted Sam Jordan for this). So take all the time you need; you're not slower than my speed of coding ;-)
Regards,
Dennis.

Hi David,
short question: Did my update of the mmu.library from last week reach
you? I'm not sure whether this email address of yours allows the attachment
of binaries.
Greetings,
Thomas

Hello,
If by David you mean me, then no. I have not seen any binaries. Which e-mail address did you use?
Regards,
Dennis

Coincedentally, I tried some stuff yesterday with manually moving the window while in interrupt (I am guessing it does it automatically when running nornal code - by another interrupt) and got some strange results like crashing when just letting the program run, while it finishes correctly when a certain amount of delay is inserted... (all without mmu.library btw).

Am 10.05.2016 um 13:57 schrieb DvdBoon:

Hello,
If by David you mean me, then no. I have not seen any binaries. Which
e-mail address did you use?

This one - on github. You probably want to send me your private mail (or
reply by that) so we don't have to go through github for communication.
Greetings,
Thomas

It's dennsvdboon at gmail

Am 10.05.2016 um 14:34 schrieb DvdBoon:
You should have mail now. Let me know whether this worked.
Greetings,
Thomas

Sorry Thomas, I made an error. It's dennisvdboon. The 'i' was missing.

Am 10.05.2016 um 15:24 schrieb DvdBoon:

Sorry Thomas, I made an error. It's dennisvdboon. The 'i' was missing.

Ok, third try. (-: Please check.
Greetings,
Thomas

Received an update of the mmu.library from Thomas. I'll be trying to get some results on my A1200 this weekend.

The PPC now starts up on the A1200 without the use of the MMU routines from the mediator (ENV:Mediator/MMU = No). It sets up its memory block of 128MB and reports it to the system. The next step is to use Thor's MMU library to shift the Z2 window around within this memory block when needed. I foresee a problem with 68K code from Z2-Window1 trying to access data from Z2-Window2. Both code and data needed by that code need to be located in 1 window. Any ideas welcome.

As we know, AmigaOS exec will by default allocate the memory with highest priority first. Typically, this is the memory on turbo board. Unless we are talking about hunk marked explicitly as Sonnet PPC/Mediator DMA. If we have all hunks in the executable marked correctly, chances of such problems are minimal. But then, if we use some automated method to patch the binary and just add the Sonnet memory extended attribute to every hunj... Of course 68k code might also end up in Sonnet memory.
Second thing... I was under impression that MMU can handle the situation where some service routine has to be executed to fetch both the code and data needed by the running application. If some 68k task is running on top of this virtual 128M address space, why does it care how often are we changing the window position? It only sees the virtual addresses. Maybe I'm missing something here?
Besides, Mediator's memory management routines do seem to work in this exact situation?

Hi folks,

As we know, AmigaOS exec will by default allocate the memory with
highest priority first. Typically, this is the memory on turbo board.
Unless we are talking about hunk marked explicitly as Sonnet
PPC/Mediator DMA. If we have all hunks in the executable marked
correctly, chances of such problems are minimal. But then, if we use
some automated method to patch the binary and just add the Sonnet memory
extended attribute to every hunj... Of course 68k code might also end up
in Sonnet memory.

Again, placing memory that is mapped by the MMU is a bad idea, and I
would highly recommend not doing so. The problem is DMA. Such memory
cannot be reached by DMA savely, even with all MMU library precautions
on exactly this matter. The problem is that many DMA devices do not use
Os functions correctly to translate logical addresses (as seen by the
CPU) to phsyical addresses (as seen by the DMA device).
The problem becomes even worse in case the memory can go away any time,
even under the feet of a device performing active DMA.

Second thing... I was under impression that MMU can handle the situation
where some service routine has to be executed to fetch both the code and
data needed by the running application.

The MMU is not the problem, the processor is. As far as I remember, the
68060 uses a restart model, i.e. in case it detects that an instruction
may create a bus error on its execution, it will first trigger the
access fault, and when returning, will execute the instruction again. As
far as I remember, there is no internal state in the 68060 (unlike
earlier models), so it has to re-fetch the instruction again. The cache
will, of course, be flushed as part of the window swap.
IOW, in such a case, you end up with a ping-pong of bus-errors, and
hence a dead-lock.
The 68030 is much more microcode driven than the 68060, and there it may
actually work because the instruction pipeline is stored as part of the
exception stackframe, but on the 68060, this is not the case - it's much
more simplified and streamlined.

If some 68k task is running on
top of this virtual 128M address space, why does it care how often are
we changing the window position? It only sees the virtual addresses.
Maybe I'm missing something here?

You're probably missing the situation where the data an instruction
addresses is in a window different from the one where the instruction
itself is.

Besides, Mediator's memory management routines do seem to work in this
exact situation?

I highly doubt this. I would rather believe that they simply ignore
the problem.
Greetings,
Thomas

I'm open for any other ideas. The way it is set up now on the A3000/A4000:
PPC sets up physical memory from 0x0 - 0x10000000
PPC MMU remaps this to logical 0x70000000 - 0x80000000
Any PPC access to logical 0x70000000 is relocated to physical 0x0
Sonnet ATU (address translating unit) maps 0x70000000 PCI memory to Physical 0x0 Sonnet memory. Sonnet memory now is visible in PCI memory starting from 0x70000000. Any access from the 68K to 0x70000000 actually gets through to Sonnet memory 0x0 thanks to the Sonnet ATU. Any access from the PPC to 0x70000000 get remapped to 0x0 thanks to the PPC MMU. So both PPC and 68K access actually 0x0 when addressing 0x70000000.
The Z3 window is from 0x60000000-0x80000000 and it also as a default points to the same addresses. (So 0x70000000 is actually 0x70000000). MMU is not in use by the pci.library (not needed).
The Z2 window is from 0x200000-0xa00000. It is mostly in a state that it points to gfx mem/gfx hardware registers courtesy of the gfx driver. (0x200000 points mostly to either 0x80000000 or 0x90000000; addresses are a little bit different then on Z3). It can move to other PCI addresses if need be. Let's for the sake of argument say that, again, sonnet memory is at 0x70000000. So if we want to access 0x70000000 as in our previous example, we need to shift the Z2 window to this address and access 0x200000 OR access 0x70000000 with the 68K MMU redirecting 0x70000000 to 0x200000. The latter keeps addressing consistent for both processors (pointers etc.). And is want I want to achieve with the mmu.library
WarpOS programs get loaded inside this 0x70000000-0x80000000 area as we can not readily distinguish 68K code from PPC code (except maybe for the first code hunk which is always 68K). So the Z2 windows needs to shift to different spots within 0x70000000-0x80000000 for the 68K to execute code or fetch data if need be.
Indeed, maybe loading data from disk by WarpOS programs would give problems....But it normally would go through 68K DOS/Read(). I don't know how DMA is in this case.
A couple of things:
Data is mostly manipulated by the PPC (for speed, why else have a PPC) and not the 68K.
68K code is kept to a minimum (mostly startup).
Mixed 68K/PPC libraries could be a problem.
I'll know after trying :-)

I'm sure the issues Thor is mentioning are valid, but this discussion is in context of Mediator 1200 series only (we don't need to mess with MMU setup on big box Mediators). In case of Mediator 1200 we don't have to worry much about DMA. Nothing besides the CPU will access Mediator 1200. Even if some A1200 turbo boards have DMA-capable devices (like SCSI controllers), they typically only DMA to on-board memory on turbo card (no one ever expected that something will sit between the turbo board and main board, which has only chip RAM). Of course I could imagine some badly written driver might try that, but I think the risk is minimal. It would be a problem if we were talking about A3000/A4000, where DMA can happen to memory located anywhere.
In context of Mediator itself, DMA can happen on the PCI bus only. Since PCI bus has separate address space (shared only through the window with 68k space), it shouldn't bother us. Such DMA-capable driver has to be specially written for the Mediator and would never use 68k addresses (since PCI device can't access 68k side at all).
Btw. On a side note, I'm sure that you know but I wanted to stress that Z2 window address can change (it's not hardcoded to be at 0x200000, but is subject to normal AutoConfig mechanism). Of course when the window is 8MB there's just no more space available so it does have to fit at 0x200000 or it won't work at all.

Just wanted to show (hopefully) how it works on the Z3 Amigas and what the problems are when transposing this on the A1200.
Also, concerning AutoConfig, only the last few updates were regarding correct error handling and giving out error messages ;-) I still need to add window size checking, for example.

Letting some time pass between various attempts to get it working on the A1200 let to the realization that maybe the 8MB window is actually made up from 2x 4MB windows.
And indeed, some testing showed that it actually is the case. I successfully pointed the first 4 MB to 0x98000000-0x983fffff and the second 4 MB window to 0x99000000-0x993ffffff (so 0x200000 pointed to 0x98000000 and 0x600000 to 0x99000000). @rkujawa It was indeed bit 12 which is the selector.
This makes it a lot easier regarding code and data in different windows.

It's certainly possible. I must have never noticed the problem on NetBSD, as if I remember correctly, I mostly tested with 4MB window.
However, I am a bit worried about trying to change window position bypassing pci.library. It might lead to some breakage of Mediator drivers. Or the these drivers might try to change window position when we least expect that.

Drivers change the window by
Disable()
origwindow=GetZorroWindow()
SetZorroWindow(driverspace)
Stuff()
SetZorroWindow(origwindow)
Enable()
The voodoo driver does this using some sort of VBlank interrupt.as far as I
can see. Even if the Disable() / Enable() pair are missing I plan on doing
a patch on SetZorroWindow to track changes. If SetZorroWindow is called the
patch should invalidate all sonnet memory by 68K MMU. Something like that.
I'm not there yet in development.
2016-07-20 9:22 GMT+02:00 Radosław Kujawa<EMAIL_ADDRESS>
It's certainly possible. I must have never noticed the problem on NetBSD,
as if I remember correctly, I mostly tested with 4MB window.
However, I am a bit worried about trying to change window position
bypassing pci.library. It might lead to some breakage of Mediator drivers.
Or the these drivers might try to change window position when we least
expect that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Sakura-IT/SonnetAmiga/issues/21#issuecomment-233863759,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKdWEESdNhX370mQpJWf1ZwiqBOAvluuks5qXcy_gaJpZM4GvuJN
.

As far as I can see, the changes to the mmu.library do what they are suppose to do. I can set up a memory range, for example 192MB at 0x40000000 for the sonnet and redirect it dynamically to the Mediator Z2 window at 0x200000. So that is good news. With FileX I can look at an arbitrary address range within that window. I can see the PPC debug output and also see the sonnet libbase and functions within this range. So also the library is correctly set up in Sonnet space.
The bad news is that shifting the Mediator window seems to interfere with the Voodoo driver. Gadgets and icons are not updated, for example. Other things like the FileX window contents are updated.
Looking a bit closer at the pci library I noticed that when the MMU is used by the pci library, the drivers only use a 4MB window, leaving the second 4MB window (at 0x600000) probably for the MMU.
Needs some more investigation.

I wonder if in this situation it would be better to use pci.library function for changing window position? At least that should solve the problem with other drivers pci.library?

I am using the functions of the pci.library at the moment. I'm not sure if I am using them correctly, though, because I lack the documentation. I can have a look at other drivers. And have another look at the bus exception handler of the pci.library.
Want I meant with above post is to let the Mediator think it has a 4MB window and directly manipulate the second window with the sonnet.library. I think that is what happens when the option MMU=yes is set. Also with that option the pci library installs its own bus exception handler and manipulates the MMU directly. We don't want that. Like I said, I am now manipulating the full 8MB window using the pci library functions with MMU=no in ENV/Mediator.

Understood. I thought you're no messing with the window register directly. I hoped that with the new version of pci.library we'd be able to avoid patching it.
I agree with the idea to use 4MB window and try to manipulate the second one with sonnet.library. Using the pci.library's MMU mode is problematic, also agreed about that. Just that when MMU=no, library assumes that it can present the whole 8MB window space to the drivers... Which again is problematic, if we want to steal half of that.

I'm going to revisit this soon. As it stands now, there are two options. One through the mmu.library (with MMU=no) and one through the pci.library (with MMU=yes).
A recent development confirmed some of the above assumptions regarding the pci.library so I want to retry that again. I think that I now know why the earlier attempts were not succesfull.
During the Sonnet Interrupt. I have to move the window myself. Normally this is done by the pci.library when MMU option is enabled but during interrupts the programmer has to do it.
Looking back to the earliest code the sonnet interrupt did move the window but not always when needed. The interrupt calls functions like putmsg, getmsg and replymsg and these functions can address memory ranges which are not within the same Z2 window thus getting the wrong info.
The solution would be to write those functions as part of the interrupt, such that the Z2 window gets moved to the right position (address of the message, address of the msglist, address of predecessor, address of successor and address of msgport for example).
Fingers crossed.
I already noticed that some WarpOS software depend on some output being negative when a failure occured. With the address range above 0x80000000 (and thus negative when signed) some of the programs don't work correctly. CyberPi for example.

wXR at EAB added a bounty for this issue:
https://www.bountysource.com/issues/28897993-get-the-sonnet-library-working-on-the-1200tx-mediator

PCI memory seems to be copyback. I need it to be cache inhibited like on the A3000/A4000. Maybe in the future this will change. Also, the address at which the WarpOS programs are running on the A1200 (>2GB range) does not help. I'm trying to get something in place that will bring it <1GB range (the max range the sonnet can install its memory into).

I have a pci.library now which sets pci memory as cache inhibited. I'll try to move all Zorro window conflicting stuff out of the interrupt and into the master control process. (Supervisor versus user mode) and see if that improve things.
The  >2 gb addresses issue still needs to be resolved too.

Again, no luck. Programs just halt after a while. Can be immediately, can be after 10 seconds. There is no crash. Both the 68K and the PPC task go to a wait status.

Seems that it is related to the time between putting data in the queue that needs to be transferred to the PPC. When a message pointer is put in a certain register of the mpc107 this pointer is automatically transferred to a circular FIFO on the PPC side and an interrupt is raised. When writing two values into this register close to each other time-wise, the first message gets lost as it is not transferred to the ppc.
I saw a same kind of behavior with the big box mediator while reading from this register. It should give unique pointers but sometimes the ppc side was not updated quickly enough and two consecutive pointers were equal. A simple compare and reread sufficed. Here it is a bit more difficult as I cannot test whether the message was updated correctly while writing. I might have to organize the FIFO manually and just use a simple interrupt when done.

There are more latency problems. Every message that goes through the ports (the 2 PCI registers on the PCI memory side, OFQPR and IFQPR, ) have a chance to be missed on the A1200 Mediator.

Looks like both the reading of free messages to send to PPC and reading of messages send from the PPC (so in both cases the 68K reading from the EUMB registers in PCI space) are affected. Now I also re-read when a duplicate is found from messages send from PPC and Voxelspace has been running for 2 hours now.
Not sure if writing to the registers is affected. I already rewrote the sending of messages to PPC, but releasing used messages is also done by writing to these EUMB registers by the 68K. However, there is a pool of 4K messages so any problems here will show up MUCH later.

Received an updated pci.library where the mediator automatically adjusts the zorro window also in the 0x10000000-0x20000000 range. Strange behaviour of some programs (Quake quitting on memory allocation error, cyberpi not printing any printf text, voxelspace not showing info window) seem to be resolved.

move.l #$89000000,a0
move.l #$8B000000,a1
move.l #$ABCDABCD,(a0)
move.l (a0),(a1)
rts
does not work with current pci.library version. Version 11.0 and 12.0 worked with above program. Back to Elbox.

Got a fixed library from Elbox and on the A1200 the Sonnet memory is now placed at 0x20000000 and up. This has solved some of the issues like no text output in WarpOS programs due to addresses being negative when >0x80000000.
Simple stuff (the demos and tools from the WarpOS distribution seem to work now on my Amiga with the latest build. So the hanging which happened intermittently was also caused by the previous version of the pci.library.
Voxelspace however seems twice as slow as normal. QuakeWOS (the software 3D version) crashes after loading AHI. There seems to be some memory trashing somewhere.

Fixed the memory error. Now another error popped up while starting QuakeWOS. Some jump to zero page.

If the Amiga OS handles anything which is in Sonnet memory, there is a chance on a crash. For example, the Wait() function inside the library crashes when entered with the 68K stackpointer pointing to Sonnet memory. I think this has something to do with the Supervisor context of the 68K MMU. The Wait() function itself calls Switch() which enters supervisor mode.
Placing a StackSwap() with a normal Amiga memory stack pointer before and after the Wait() fixes this issue, but any switch to Supervisor mode with for example the 68K stack pointing to Sonnet Memory or the task structure itself residing in Sonnet memory can (not always) lead to a crash.
I have to contact Elbox to if their library uses the Supervisor context MMU (correctly). I know it is fully functional in mmu.library. Maybe consider again to try to implement the mmu.library.
A complete rewrite of the AllocMem() patch is also a posibilty. 68K stack, 68K task structures needs to go to 68K memory, PPC segments, PPC library/device bases need to go to Sonnet memory.
Seems more more and harder to implement, though.

QuakeWOS was hanging as data was not loaded correctly. De first 16 bytes of files are skipped if the buffer of Read() is in PPC memory. This has been fixed for now by intercepting the Read() and putting the buffer in FAST RAM and then copy it to PPC memory. Now QuakeWOS runs with sound off.
With sound on it still hangs during sound initialization.
Most apps work now. Audio does not work. Warp3D needs testing.


Could not create service provider after delete application role

Describe the issue:

Create new service provider with name localhost8080.com, Application/localhost8080.com role will be create
Delete role Application/localhost8080.com
Show list Service Provider, you not see the service provider. Then, create new service provider name localhost8080.com again. A dialog will be show "An application with name: 'localhost8080.com' already exists in tenantDomain: carbon.super"

Environment information:

Product Version: IS wso2is-5.11.0-alpha3
OS: Linux mint
Database: H2(default
Userstore: Primary (default)

Looks like expected behaviour.
The user does not have necessary permission to view the SP, after removing the role.
But the application is still there.

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


It keeps saying sign in although I am signed in

Describe the bug
I just created an account and purchase a license, I keep seeing the sign in button that takes me to the browser where I am signed in, and the menu bar also shows that I am signed in as it says sign out and manage.
I was expecting to see my account in there.
To Reproduce
No response
Expected behavior
No response
Diagnostic report (required)
OrbStack info:
Version: 1.0.0
Commit: bcfa4806afd6caa33f7bdbae2e81becb73ee0fdd (v1.0.0)
System info:
macOS: 13.5.2 (22G91)
CPU: arm64, 10 cores
CPU model: Apple M1 Pro
Model: MacBookPro18,3
Memory: 32 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2023-09-21T16-20-59.368225Z.zip

Screenshots and additional context (optional)
No response

Working on this — right-click > "Refresh" should fix it for now.

Refresh does nothing for me, just FYI

congrats on v1, same here, refresh didn't work

Fixed, sorry about that. It should work if you fully restart the app, and if necessary, sign in one more time if requested. (No update needed.)

Fully restarting is Quit and Open? It still not woring for me 🤔 . I am using Brave as the browser, not sure if that might have anything to do with it.

Sign out from the menu gives me this:
Exited with status 1:
run command '[/Applications/OrbStack.app/Contents/MacOS/../Frameworks/OrbStack Helper.app/Contents/MacOS/OrbStack Helper set-refresh-token ]': exit status 2; output: panic: set keychain: The specified item already exists in the keychain. (-25299)

goroutine 1 [running]:
main.check(...)
github.com/orbstack/macvirt/vmgr/main.go:87
main.runSetRefreshToken(...)
github.com/orbstack/macvirt/vmgr/privhelper.go:17
main.main()
github.com/orbstack/macvirt/vmgr/main.go:908 +0x1e4

Fixed in the latest hotfix, v1.0.0 (16230). You can get it at OrbStack menu > Check for Updates.


Azure SQL Connector - Internal Server Error

I am trying to setup MS Search using an Azure SQL Connector using the following guide: https://docs.microsoft.com/en-us/microsoftsearch/mssql-connector. When I try to test the connection to the database, I am getting the following error: "There was an internal server error while processing the request."

I made sure the correct IP's are allowed for the Azure database (I even tried the range <IP_ADDRESS> - <IP_ADDRESS>).
The client ID and secret are correct for the app registration in AAD.
I used Fiddler to check if there was more info available but there isn't, except an call to the logclient containing the following data:
[{         "TagId": 504760,         "LogLevel": 1,         "Message": "GeneralException",         "Adhoc0": "06a5f773-d06f-44ca-bd65-78b8c3a3f497",         "Adhoc1": "657",         "Adhoc2": "{\"data\":{\"ApiContext\":\"upsertAuthentication\",\"requestId\":\"893f91e9bc1ddf4f85104b4d3275798b\"}}"     }, {         "TagId": 500781,         "LogLevel": 4,         "Message": "UI Exception: GeneralException",         "Adhoc0": "06a5f773-d06f-44ca-bd65-78b8c3a3f497",         "Adhoc1": "657",         "Adhoc2": "{\"version\":\"2<IP_ADDRESS>\",\"stack\":\"Error: GeneralException\\n    at Function.e.error (https://admin.microsoft.com/Adminportal/Home:298:90469)\\n    at F (https://prod.msocdn.com/M365/admin-main/2<IP_ADDRESS>/inline.en.7666.chunk.js:1:44845)\\n    at https://prod.msocdn.com/M365/admin-main/2<IP_ADDRESS>/inline.en.7666.chunk.js:1:43386\"}"     }, {         "TagId": 500298,         "LogLevel": 1,         "Message": "UI Analytics",         "Adhoc0": "06a5f773-d06f-44ca-bd65-78b8c3a3f497",         "Adhoc1": "658",         "Adhoc2": "{\"data\":{\"location\":\"/MicrosoftSearch/Connectors/add\",\"hint\":\"ConnectorErrorBar\",\"value\":\"28cc3842-3b45-4a8e-b681-102160bed2cd|udt_0|auth failure\"}}"     } ]
Thats all the info I am getting. What else could I be missing that is not in the docs link above?

Hello @JoeydeRijk7, please send a link to this issue to Microsoft Graph Connectors Feedback<EMAIL_ADDRESS>and include the following information:

The Tenant ID
Timestamp of the most recent occurence of the issue


feat: add FoxIcon to ConnectWallet page

Description

Add FOX icon to the splash page
Update sidebar background with a slightly different one

Issue (if applicable)

closes #
Risk

High Risk PRs Require 2 approvals

low risk

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Testing

Engineering

Operations

[ ] :checkered_flag: My feature is behind a flag and doesn't require operations testing (yet)

On the connect wallet page, you will see the fox icon at the top.
Screenshots (if applicable)

Fixes #7823 , however.....

FWIW, @reallybeard the breakpoints on the more chonky screen like a laptop totally messed with the gradient sizing.

Yeah, that's fair, still trying to figure out the new branding assets. Probably needs another pass for tweaks and more luster.


When I stage a selected range, VSCode commits the entire file (staged AND unstaged parts)

VSCode Version: 1.24.1
OS Version: macOS high sierra

Steps to Reproduce:

Go in Source Control
Select a file to display the diff
Select a line of diff
cmd+shift+P > Git: Stage Selected Ranges
Commit with the icon (or cmd+shift+P > Git: Commit Staged, same bug)

Then the entire file is commited.
Here a screenshot where we see a file with a staged line and the other part not staged:

Then when I commit, VSCode commits both part, staged and unstaged.

I am also having this problem. I'm happy to provide more details. How much of the git log do you want to see?

If you have a reproducible case, make sure to send post the exact two files (old version and new version) and tell me which chunk you're trying to stage.


BUG: interpolate/fitpack: fix memory leak in splprep

Reference issue
Closes: gh-11121
What does this implement/fix?
Fixes a memory leak in splprep.
These two issues in the C code appear clear once you notice them. We don't currently have test suite machinery for checking this type of leaks, so no tests can be added, but checked manually and with pytest-leaks.

Merged, thanks @pv


Updated inceptionV3 to accept different sized images

The update allows inceptionV3 to process images larger or smaller than prescribed image size (299x299). Will be useful while finetuning or testing on different resolution images.

superseeded by https://github.com/pytorch/vision/pull/744


Add a CodeLens API sample

CodeLens Sample
This is a sample extension that shows the usage of the CodeLens API.
It is not intended as a production quality extension.

Create a new file
Write anything
Click on the CodeLens for action example
Can be enabled or disabled by command palete

How it works, what it shows?

The extension uses the CodeLens

How to run locally

open this folder in VS Code and press F5

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

@octref Why not merge this?

Ping @octref, please assign to someone else if you're not going to take this.

@octref  All should be resolved.

LGTM, thanks!


run configuration

To be able to run and build project directly from VS Code

For not can just use tasks.json:
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Build The",
      "command": "the build",
      "problemMatcher": [],
      "group": "build",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "Run The",
      "command": "the run build/result",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    }
  ]
}

Re-opened to pin

I'm not VS  Code user so it might be not optimal for people to use tasks. If it's so, please let me know here


Book: Code block line numbers

Currently the book uses<EMAIL_ADDRESS>which:

Breaks code snippet copying: As it uses <table> elements, it causes the copied code to contain extra newlines.
Also necessitates a lot of hacky CSS rules so that mdbook's table styling doesn't interfere with the code blocks' styling.

Probably worth writing the same functionality without using <table> elements.
Figure out how to add <span>s for each line in the code block as a hljs plugin, then CSS counters to add the counter.
Links:

highlight.js
wcoder/highlightjs-line-numbers.js
[mdn] counter-increment
[blog] using-css-to-add-line-numbering
[so] create-line-numbers-on-pre-with-css-only

Closed by #163 in commit fcc0cb5d.
Source code of the highlightjs line numbers is at: https://github.com/azriel91/highlightjs-line-numbers.js/blob/feature/mdbook-support/src/highlightjs-line-numbers.js
Permanent solution would be solved in: https://github.com/rust-lang/mdBook/issues/1303